Feature request: Expand macro single step

[CAD97]

We already have the "Expand macro recursively" action, which is useful for seeing what a macro eventually expands to if it successfully expands. However, for debugging e.g. tt muncher macros, it can be very useful to expand a single step in macro expansion, to track how the macro processes along the way.

A key feature is that it can't just show the first level of expansion, it also has to be possible to choose any macros in the output and expand those (a single step).

[Veykril]

Easily going back up into the previous expansion would also be very nice to have (basically full expansion tree traversal)

cc #5949, #10548

[tfpk]

Howdy -- I'm currently taking a look at this (particularly because it'd work really well with my macrokata project).

My plan is the following: create an action very similar to expandMacro, but rather than popping open a new window, do an in-place replacement. This will mean that going in and out of depth is very easy (going backwards is just an undo, going forwards is a repetition of the expandSingleMacro command).

Some questions that I'd like to raise as I'm working on this:

• This is not a "safe" operation (in that it can produce correct but different code) -- is it worth wrapping expansions in unsafe? Or are we happy that anyone using this operation should know it's not perfect?
• Is it more important to expand $crate (which is more likely to lead to working code), or should we leave it un-expanded so it's a literal expansion of the macro?

Would appreciate your perspective! Thanks :)

[Veykril]

What you want to do sounds more like #13598

This is not a "safe" operation (in that it can produce correct but different code) -- is it worth wrapping expansions in unsafe? Or are we happy that anyone using this operation should know it's not perfect?

unsafe has a completely different meaning, so that's not a good idea, its fine if the action isnt perfect, a lot of r-a's assists are still imperfect

Is it more important to expand $crate (which is more likely to lead to working code), or should we leave it un-expanded so it's a literal expansion of the macro?

Ideally we'd replace that with the proper crate identifier, but that is somewhat tricky to do since the crate name changes depending on the crate we are inlining the expansion into.

But ye, any discussions regarding your idea would be better suited in the linked issue I think.

[crazymerlyn]

Should this be marked fixed with #13810 or is there anything still left to be done?

[Veykril]

That one is a different thing. What the issue talks about here is merely viewing a single macro expansion step (and then potentially step further).

[crazymerlyn]

I'm not sure I understand. From what I can see, the current "Inline macro" code action only expands one level of macro.

For example, when using "Inline macro" on

macro_rules! calculate {
    ($e:expr) => {{ $e }};
    ($e:expr, $($es:expr),+) => {{
        $e +
        calculate! { $($es),+ }
    }};
}

fn main() {
    let _a = calculate! {1,2,3};
}

I get:

macro_rules! calculate {
    ($e:expr) => {{ $e }};
    ($e:expr, $($es:expr),+) => {{
        $e +
        calculate! { $($es),+ }
    }};
}

fn main() {
    let _a = {
  1+calculate!{
    2,3
  }
};
}

Do you mean something else when you say "one step"?

[CAD97]

The "expand macro recursively" intent shows the macro expansion in a fresh window without editing the source. "Expand macro inline" does work to satisfy the underlying desire, but a full realization of the feature request is more like an interactive macro debugger, able to step through expansion to determine what's being done without modifying the original source. (But "expand macro inline" is the functionality which would power the visualization (almost, because hygiene).)