Refactor and improve macro debugging/general utilities

[RDambrosio016]

Rust analyzer's expand macro recursively command is nice, however, it is also greatly flawed and provides little to no utility for debugging more complex macros. This issue is aimed at refactoring it and turning it into a useful tool.

Flaws with expand macro recursively

• No formatting is applied to the expanded code, most people dont care about formatting inside macros, so the output ends up looking pretty horrid.
• The macro expander expands all the macros recursively (duh). This may seem useful, but it often just causes more confusion around what is coming from the main macro and what is recursively expanded, and it generally just outputs miscellaneous code you dont care about.
• There is no way of knowing what code came from what binding, and the expansion does not show the macro either, so now you have to go back and forth to try and see what is what.

Proposal for refactoring the command

Instead of a simple text read only editor, we can make use of vsc's custom editor windows extension to make a prettier and more useful editor.
The changes would have to be made in steps:

• Refactor hir::sema::expand to give more info about what code came from what binding, i suspect this will be the hardest part.
• Implement a basic editor which colors code blocks depending on where they came from.
• (maybe) implement highlighting in the actual source code when the editor is live.
• Make an experimental command (not sure of how RA handles experimental features).
• Deprecate the expand macro recursively command and eventually phase it out.

Challenges

• Not all macros are pretty, some are very cursed, especially recursive macros, displaying them in a nice way is going to be a challenge.
• Modeling what bindings created what code may be a challenge in the expansion code.
• Good editor design is hard :(

So what might it look like? 👀

I am by no means a design guy, and i realize this is a blob of colors, but this is conceptually what it might look like:

If anyone has suggestions then please put them below.

[matklad]

As a more x-editor alternative, we can implement a custom "macro explorer" virtual buffer with a special language type, where we can use custom syntax highlighting, assists, etc. That is, the 💡 Explore Macro Call opens a split editor with one-level macro expansion, where there's 💡 Expand on each specific recursive call, which changes the text in-place.

[matklad]

Actually, I think just "expand macro in-place" code action might improve usability a bunch?

[ahicks92]

As a blind user who happened to stumble on this and could certainly have used macro debugging tools the other day, going to just chime in that custom editors are difficult from an accessibility perspective and that the built-in VSCode pieces (generally) just work.

That's not to say you can't make an accessible editor, but most of the off-the-shelf things you'd grab off NPM or whatever else will usually be entirely inaccessible because they implement the entire thing with CSS and divs/spans/insert-your-favorite-inaccessible-technique. I'm very definitely a backend guy, so I can't provide an accessible option here I'm afraid, but VSCode had to put a tremendous amount of effort into getting their component to work reliably with screen readers by basically implementing a second mode where the thing is an actual multiline text field, then adding a whole other virtual paging thing on top to deal with some screen reader/chrome bugs that exist for very silly reasons. I think that's both a statement as to the complexity and a possible option being as I think their component is either separated or at least separable from VSCode. Also I think VSCode offers some sort of component library for extension authors that's supposed to be accessible, but i'm not sure on the details.

I think my ideal would be some sort of expansion inline, but I haven't given what the UX here would look like much thought and the version I'd want vs. the version someone sighted would want are probably very different.