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?