Tracking issue for RFC 2091: Implicit caller location

[aturon]

This is a tracking issue for the RFC "Implicit caller location" (rust-lang/rfcs#2091).

Steps:

• Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

• If we want to support adding #[track_caller] to trait methods, the redirection
  pass/query/whatever should be placed after monomorphization, not before. Currently the RFC
  simply prohibits applying #[track_caller] to trait methods as a future-proofing measure.

• Diverging functions should be supported.

• The closure foo::{{closure}} should inherit most attributes applied to the function foo, in
  particular #[inline], #[cold], #[naked] and also the ABI. Currently a procedural macro
  won't see any of these, nor would there be anyway to apply these attributes to a closure.
  Therefore, #[rustc_implicit_caller_location] currently will reject #[naked] and ABI, and
  leaving #[inline] and #[cold] mean no-op. There is no semantic reason why these cannot be
  used though.

[eddyb]

If we want to support adding #[track_caller] to trait methods,

This refers to impl of a trait, not the declarations within the trait, right?

IMO the easiest way to implement this involves no procedural macros or MIR passes.
We'd just pass extra arguments on direct calls, and require a shim to get function pointers of the function. That would also surely work with trait methods, since it'd be post-monomorphization.

To explain, the shim (which we may already have some variation of) would "just" do the direct call to the function, which would pass the location of the shim, the same as the original function.

[nikomatsakis]

This refers to impl of a trait, not the declarations within the trait, right?

I can't remember. =) But I suspect so. I don't think there's anything special about "trait methods" per se -- it's really about dynamic dispatch.

[nikomatsakis]

@kennytm had a prototype implementation:

https://github.com/kennytm/rust/tree/caller-info-4

Maybe @kennytm you can summarize the approach you took? Do you think you'll have time to rebase etc? I'd like ideally to get @eddyb to buy in to the overall approach. =)

[kennytm]

The prototype implementation works like this (note that #[track_caller] was called #[implicit_caller_location] there):

1. First there will be an AST transformation pass (implemented as an attribute proc-macro in src/libsyntax_ext/implicit_caller_location.rs) which expands:

   #[track_caller]
   #[...attributes...]
   fn foo(...) -> T {
       /* code... */
   }

   into

   #[rustc_track_caller]
   #[inline]
   #[...attributes...]
   fn foo(...) -> T {
       let __closure = |__location| { /* code... */ };
       FnOnce::call_once(__closure, intrinsics::caller_location())
   }

   The purpose of this pass is to conveniently make up a new DefId.

2. Create a new MIR inlining pass (main implementation in src/librustc_mir/transform/inline.rs). This pass does two things:

   1. Force-inline any functions calls foo() where the attributes of the callee foo contains #[rustc_track_caller].

   2. If intrinsics::caller_location() is called :-

      • If it is used from the __closure, replace it by the argument __location. This is to propagate the caller location.
      • Otherwise, replace the call with the caller's location span.

3. Define the caller_location() intrinsic.

   fn caller_location() -> core::panic::Location<'static>;

4. Because Location now needs to be known by the compiler, make the Location struct a lang-item.

5. Update the standard library to use track-caller features:

   1. Change panic! to use caller_location() (or its safe counterpart, Location::caller())
   2. Add #[track_caller] to unwrap() and expect() etc.

6. Implement the -Z location-detail flag (search for location_detail) so that the filename/line/column can be redacted.

[eddyb]

I think a syntactical transformations is unnecessary because we can instead change the "direct call ABI" (vs reifying to a fn pointer, including trait vtables via miri, which could go through a MIR shim).
MIR inlining should also not be needed.

[kennytm]

@eddyb So you are suggesting to change the extern "Rust" ABI to always pass an extra argument?

[eddyb]

@kennytm Only for functions declared with the attribute and called through static dispatch, everything else would use a shim when reifying (which I think we do already in some other cases).

[kennytm]

@eddyb Maybe you could write down some mentoring instructions i.e. which files to look at 😊

[nikomatsakis]

@eddyb do it! do it! I want this feature.