RFC: Debuggable macro expansions

[hsivonen]

Improves debuggability of, panic stacks for and profiling attribution of code expanded from non-assert-like macros.

By default, annotate code expanded from a macro with debug location info corresponding to the macro definition (i.e. the behavior that's currently available on nightly via -Zdebug-macros). Add an annotation #[collapse_debuginfo] to enable a particular macro definition to opt to have the expansion annotated with debug location info corresponding to the macro invocation (i.e. the current default behavior).

Rust issue, PR that created the current behavior, Internals forum post

Rendered

[michaelwoerister]

Thanks a lot for the RFC, @hsivonen! I think this is a good idea as proposed.

Regarding the open questions:

• I think -Zdebug-macros should go away, once this is stable.
• I think one should not be able to step into code that was passed as an argument to a #[collapse_debuginfo] macro, just for consistency.

cc @vadimcn and @rust-lang/compiler (and maybe @rust-lang/lang and @rust-lang/dev-tools should take a quick look at this too).

[aturon]

For context, these issues are a problem for some of our production customers. It'd be good to get feedback from the compiler team soon.

[kennytm]

I think the behavior of #[collapse_debuginfo] should be like this:

fn f() {              // 17
    {                 // 18
        one();        // 18
        {             // 18
            two();    // 18
        }             // 18
        {             // 18
            three();  // 19 <--- retain line number if the statement comes from macro invocation
            four();   // 20 <---
        }             // 18
    }                 // 18
}                     // 22

[nrc]

Related, for error messages, we apply a same-crate heuristic, where if the macro is in the same crate, we give details from inside the macro, and if not we treat it as opaque. If we add an attribute like #[collapse_debuginfo], should it also affect error messages (i.e., replace the same-crate heurictic)?

[vadimcn]

I think this proposal looks reasonable. Thanks for writing it up!

Re unsolved questions: if code blocks passed as macro argument are not affected by #[collapse_debuginfo], it might break "step-over" functionality in debuggers, so this scenario needs to be tested if you decide to go this route.

[aturon]

@michaelwoerister do you want to move toward FCP at this point, to land this ahead of the impl period?

[nrc]

We discussed this in dev-tools meeting today. We approve of the RFC in principal, but would like to experiment with an implementation. Given the impl period, we'll not do anything with this RFC for now, but consider us approving a hypothetical 'experimental RFC' so that we can experiment with an unstable implementation. We'll revisit this RFC once we have some experience with the implementation.

[tromey]

I think "on debuggable" should be changed "not debuggable" here, and "at that" should be changed to "and that" on the subsequent line.

[nrc]

@michaelwoerister @tromey @hsivonen @vadimcn is anyone interested in doing an initial implementation of this? I think that is the next step here.

[gbutler69]

@hsivonen

While the distinction between assert-like and non-assert-like and the desired behavior is clear and tied to the nature of the macro and, therefore, it's OK to leave the decision on the debug info behavior to the macro definition site, the desired results for println-like macros are somewhat more dependent on the circumstances of the macro user, but this solution still leaves the decision to the crate that defines a macro as opposed to the crate invoking the macro.

Would it make sense to have an attribute that could annotate the call-site of the macro to select collapsed vs expanded debug info which overrides the setting made at the macro declaration site?

[hsivonen]

Would it make sense to have an attribute that could annotate the call-site of the macro to select collapsed vs expanded debug info which overrides the setting made at the macro declaration site?

For the use cases I've encountered so far, the choice has been something that'd belong better on the macro declaration than on the macro invocation.

I don't know if others have use cases where being able to override the choice from the macro invocation site would make sense, but I'm pretty confident that at least the primary choice belongs in the macro declaration.

[ngugc]

Hi, any update here? It has been a year and a half since last update.

[pnkfelix]

Discussed at T-lang backlog bonanza.

Points of feedback:

• This is a scenario where we agree that a real problem exists. We think the problem might be defined as "it should be easier to debug code that was expanded from macros." Our team would prefer to charter a group to look at the solution space for this problem, rather than trying to evaluate a specific RFC outlining one particular solution.

• This seems like this could/should be a major change proposal (MCP) for the compiler team, rather than an RFC for the language team.

• If a solution is reasonably narrow in scope, then it may be able to land without having to go through the bureaucratic overhead of the RFC process.

We recommend you file a compiler-team MCP, if you think you yourself have time to do the associated work associated with implementing the change or chartering a project group to do the prototyping described above. If the implementation effort requires the addition of small attributes or other small changes, those can be discussed by the T-lang design team concurrently with the ongoing implementation effort.

[nikomatsakis]

Based on the above, I'm going to go ahead and close this RFC -- as @pnkfelix noted, I think the best next step is to work towards the implementation side.

[hsivonen]

Filed an MCP.