Stabilize core::panic::Location::caller

[dtolnay]

The lang FCP for #[track_caller] is happening in #72445. This is a libs FCP for https://doc.rust-lang.org/nightly/std/panic/struct.Location.html#method.caller which is under the same feature gate and required for making use of #[track_caller] in library code.

Refer to @anp's stabilization report and the method's example code.

In particular:

• The return type is &'static Location<'static> which resembles the return type of std::panic::PanicInfo::location (Option<&'a Location<'a>>) but static and non-optional.

• The location points to the outermost call site not inside of a #[track_caller] function.

#[track_caller]
fn f() -> &'static Location<'static> {
    Location::caller()
}

fn g() -> &'static Location<'static> {
    f() /*
    ^ calling g() gives a location whose file()/line()/column() point to here
        */
}

@rust-lang/libs

[dtolnay]

@rfcbot fcp merge

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @SimonSapin
• @dtolnay
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Aaron1011]

Was a decision ever reached on #69977? It's currently impossible to determine which method call in a chain (e.g. foo.a().b().c() is the actual caller, since a call from any of them will cause Location::caller to point to the beginning of the call chain.

[Aaron1011]

and required for making use of #[track_caller] in library code.

That's only true if a library wants to programatically inspect the caller, right? It's possible to use #[track_caller] only for its effect on panicking, which doesn't require libraries to use Location::caller

[anp]

Was a decision ever reached on #69977? It's currently impossible to determine which method call in a chain (e.g. foo.a().b().c() is the actual caller, since a call from any of them will cause Location::caller to point to the beginning of the call chain.

I don’t think any action was decided upon here. I think we can “enhance” the Location type with span end info separately from this feature. I can see an argument for gating stabilization on fixing the underlying issue with spans, but I’m obviously inclined to treat it as a follow up :).

[anp]

and required for making use of #[track_caller] in library code.

That's only true if a library wants to programatically inspect the caller, right? It's possible to use #[track_caller] only for its effect on panicking, which doesn't require libraries to use Location::caller

This is correct, for custom error types to get the improved panic messages earlier, we could stabilize the attribute separately from the intrinsic wrapper. This seems like a good option to exercise if there are concerns about this FCP which wouldn’t block the attribute from stabilizing, as it would decouple schedule pressures.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[Aaron1011]

I think we can “enhance” the Location type with span end info separately from this feature.

Does this mean that 'span start' info (currently Location::{file, line, column}) will always point to the start of the method chain? If so, I think it should be mentioned in the stabilization report and docs.

[SimonSapin]

Why shouldn’t each call in a chain have its own span?

[anp]

AIUI there’s a limitation in how MIR propagates spans in method chains but @eddyb should correct me.

[anp]

I think we can “enhance” the Location type with span end info separately from this feature.

Does this mean that 'span start' info (currently Location::{file, line, column}) will always point to the start of the method chain? If so, I think it should be mentioned in the stabilization report and docs.

I would expect that to change if the Location type became aware of span start/ends, or if MIR becomes able to more accurately provide a span start within the middle of the chain. This doesn't seem problematic to me in general but that's operating from the assumption that changes to span reporting wouldn't be breaking changes. Maybe that assumption is in error?

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[Aaron1011]

Can this issue be closed now that Location::caller() has been stabilized?