New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Debuggable macro expansions #2117

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
@hsivonen
Copy link

hsivonen commented Aug 18, 2017

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

This comment has been minimized.

Copy link

michaelwoerister commented Aug 21, 2017

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

This comment has been minimized.

Copy link
Member

aturon commented Aug 22, 2017

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

This comment has been minimized.

Copy link
Member

kennytm commented Aug 23, 2017

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 nrc added the T-dev-tools label Aug 23, 2017

@nrc

This comment has been minimized.

Copy link
Member

nrc commented Aug 23, 2017

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

This comment has been minimized.

Copy link
Contributor

vadimcn commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Member

aturon commented Sep 6, 2017

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

@nrc

This comment has been minimized.

Copy link
Member

nrc commented Sep 19, 2017

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.

results for macros that are not assert-like and not print-like but that expand
to substantial code. The current approach of collapsing debug information by
default makes non-assert-like, non-print-like macro usage result in code that
is on debuggable, that doesn't get useful panic/crash stacks in CI or in the

This comment has been minimized.

@tromey

tromey Jan 25, 2018

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

@nrc

This comment has been minimized.

Copy link
Member

nrc commented Feb 1, 2018

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

@gbutler69

This comment has been minimized.

Copy link

gbutler69 commented Jun 6, 2018

@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

This comment has been minimized.

Copy link

hsivonen commented Jun 7, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment