Skip to content
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

#[track_caller] should inherit through specialization ancestors, too? #70293

Open
anp opened this issue Mar 23, 2020 · 2 comments
Open

#[track_caller] should inherit through specialization ancestors, too? #70293

anp opened this issue Mar 23, 2020 · 2 comments
Labels
A-specialization Area: Trait impl specialization F-specialization `#![feature(specialization)]` F-track_caller `#![feature(track_caller)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@anp
Copy link
Member

anp commented Mar 23, 2020

The current implementation of #[track_caller] allows trait methods to have the annotation, including at their definition site. When applied in a trait definition, the attribute has effect on all impls. @eddyb raised the question in code review of whether you should also be able to add the attribute without adding an implementation as part of a specialization chain.

To me this seems like the correct semantics given what we'd like the non-specialized behavior to be. It's probably a little complicated to implement.

@Centril Centril added A-specialization Area: Trait impl specialization F-specialization `#![feature(specialization)]` F-track_caller `#![feature(track_caller)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Mar 23, 2020
@eddyb
Copy link
Member

eddyb commented Mar 23, 2020

whether you should also be able to add the attribute without adding an implementation as part of a specialization chain

To be clear, what I was thinking of is something like this:

trait Foo {
    fn foo();
}

impl<T> Foo for T {
    #[track_caller]
    default fn foo() { panic!("default") }
}

impl Foo for () {
    fn foo() { panic!("final") }
}

IIUC (and I suppose you could add a testcase like this), the current implementation results in the "final" method not being #[track_caller], only the T != () "default" will have it.

And my suggestion was that long-term we might want "final" to get #[track_caller] from specializing "default".

The implementation might not be difficult, I just am not sure what the "ancestors" specialization graph traversal lets you do, yet.
It might be even simpler than the current implementation, which looks only at the trait for an inherited #[track_caller] (as specialization infra may do things like matching by name, all by itself).

@anp
Copy link
Member Author

anp commented Mar 23, 2020

Hm, I see yeah. This "just works" for default trait impls/overriding trait impls right now, so I imagine the trick would be to run should_inherit_track_caller in a loop on specialization ancestors?

Manishearth added a commit to Manishearth/rust that referenced this issue Jun 30, 2020
Stabilize `#[track_caller]`.

# Stabilization Report

RFC: [2091]
Tracking issue: rust-lang#47809

## Summary

From the [rustc-dev-guide chapter][dev-guide]:

> Take this example program:

```rust
fn main() {
    let foo: Option<()> = None;
    foo.unwrap(); // this should produce a useful panic message!
}
```

> Prior to Rust 1.42, panics like this `unwrap()` printed a location in libcore:

```
$ rustc +1.41.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value',...core\macros\mod.rs:15:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
```

> As of 1.42, we get a much more helpful message:

```
$ rustc +1.42.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', example.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

> These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information.

The attribute adds an implicit caller location argument to the ABI of annotated functions, but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator.

## Bottom Line

This PR stabilizes the use of `#[track_caller]` everywhere, including traits and extern blocks. It also stabilizes `core::panic::Location::caller`, although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`.

The implementation for the feature already changed the output of panic messages for a number of std functions, as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44.

## Tests

All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo.

Noteworthy cases:

* [use of attr in std]
  * validates user-facing benefit of the feature
* [trait attribute inheritance]
  * covers subtle behavior designed during implementation and not RFC'd
* [const/codegen equivalence]
  * this was the result of a suspected edge case and investigation
* [diverging function support]
  * covers an unresolved question from the RFC
* [fn pointers and shims]
  * covers important potential sources of unsoundness

## Documentation

The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide].

I have an [open PR to the reference][attr-reference-pr] documenting the attribute.

The intrinsic's [wrapper] includes some examples as well.

## Implementation History

* 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) rust-lang#65037](rust-lang#65037)
  * Picked up the patch that @ayosec had started on the feature gate.
* 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 rust-lang#2/N) rust-lang#65182](rust-lang#65182)
* 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) rust-lang#65258](rust-lang#65258
  * Abandoned approach to send location as a MIR argument.
* 2019-10-28: [`std::panic::Location` is a lang_item, add `core::intrinsics::caller_location` (RFC 2091 3/N) rust-lang#65664](rust-lang#65664)
* 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) rust-lang#65881](rust-lang#65881)
* 2020-01-04: [libstd uses `core::panic::Location` where possible. rust-lang#67137](rust-lang#67137)
* 2020-01-08: [`Option::{expect,unwrap}` and `Result::{expect, expect_err, unwrap, unwrap_err}` have `#[track_caller]` rust-lang#67887](rust-lang#67887)
* 2020-01-20: [Fix #[track_caller] and function pointers rust-lang#68302](rust-lang#68302) (fixed rust-lang#68178)
* 2020-03-23: [#[track_caller] in traits rust-lang#69251](rust-lang#69251)
* 2020-03-24: [#[track_caller] on core::ops::{Index, IndexMut}. rust-lang#70234](rust-lang#70234)
* 2020-04-08 [Support `#[track_caller]` on functions in `extern "Rust" { ... }` rust-lang#70916](rust-lang#70916)

## Unresolveds

### From the RFC

> Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing
> measure.

**Resolved.** See the dev-guide documentation and the tests section above.

> Diverging functions should be supported.

**Resolved.** See the tests section above.

> The closure foo::{{closure}} should inherit most attributes applied to the function foo, ...

**Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation.

### Binary Size

I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support.

There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the "right" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction.

### Specialization

There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable, but I also think it should be an easy question to resolve.

### Location only points to the start of a call span

rust-lang#69977 was resolved by rust-lang#73182, and the next step should probably be to [extend `Location` with a notion of the end of a call](rust-lang#73554).

### Regression of std's panic messages

rust-lang#70963 should be resolved by serializing span hygeine to crate metadata: rust-lang#68686.

[2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md
[dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html
[specialization]: rust-lang#70293
[measure-size]: rust-lang#70579
[mitigate-size]: rust-lang#70580
[attr-reference-pr]: rust-lang/reference#742
[wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller
[tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller
[const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs
[diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs
[use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs
[fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs
[trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs
[1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages
Manishearth added a commit to Manishearth/rust that referenced this issue Jun 30, 2020
Stabilize `#[track_caller]`.

# Stabilization Report

RFC: [2091]
Tracking issue: rust-lang#47809

## Summary

From the [rustc-dev-guide chapter][dev-guide]:

> Take this example program:

```rust
fn main() {
    let foo: Option<()> = None;
    foo.unwrap(); // this should produce a useful panic message!
}
```

> Prior to Rust 1.42, panics like this `unwrap()` printed a location in libcore:

```
$ rustc +1.41.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value',...core\macros\mod.rs:15:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
```

> As of 1.42, we get a much more helpful message:

```
$ rustc +1.42.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', example.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

> These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information.

The attribute adds an implicit caller location argument to the ABI of annotated functions, but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator.

## Bottom Line

This PR stabilizes the use of `#[track_caller]` everywhere, including traits and extern blocks. It also stabilizes `core::panic::Location::caller`, although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`.

The implementation for the feature already changed the output of panic messages for a number of std functions, as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44.

## Tests

All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo.

Noteworthy cases:

* [use of attr in std]
  * validates user-facing benefit of the feature
* [trait attribute inheritance]
  * covers subtle behavior designed during implementation and not RFC'd
* [const/codegen equivalence]
  * this was the result of a suspected edge case and investigation
* [diverging function support]
  * covers an unresolved question from the RFC
* [fn pointers and shims]
  * covers important potential sources of unsoundness

## Documentation

The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide].

I have an [open PR to the reference][attr-reference-pr] documenting the attribute.

The intrinsic's [wrapper] includes some examples as well.

## Implementation History

* 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) rust-lang#65037](rust-lang#65037)
  * Picked up the patch that @ayosec had started on the feature gate.
* 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 rust-lang#2/N) rust-lang#65182](rust-lang#65182)
* 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) rust-lang#65258](rust-lang#65258
  * Abandoned approach to send location as a MIR argument.
* 2019-10-28: [`std::panic::Location` is a lang_item, add `core::intrinsics::caller_location` (RFC 2091 3/N) rust-lang#65664](rust-lang#65664)
* 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) rust-lang#65881](rust-lang#65881)
* 2020-01-04: [libstd uses `core::panic::Location` where possible. rust-lang#67137](rust-lang#67137)
* 2020-01-08: [`Option::{expect,unwrap}` and `Result::{expect, expect_err, unwrap, unwrap_err}` have `#[track_caller]` rust-lang#67887](rust-lang#67887)
* 2020-01-20: [Fix #[track_caller] and function pointers rust-lang#68302](rust-lang#68302) (fixed rust-lang#68178)
* 2020-03-23: [#[track_caller] in traits rust-lang#69251](rust-lang#69251)
* 2020-03-24: [#[track_caller] on core::ops::{Index, IndexMut}. rust-lang#70234](rust-lang#70234)
* 2020-04-08 [Support `#[track_caller]` on functions in `extern "Rust" { ... }` rust-lang#70916](rust-lang#70916)

## Unresolveds

### From the RFC

> Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing
> measure.

**Resolved.** See the dev-guide documentation and the tests section above.

> Diverging functions should be supported.

**Resolved.** See the tests section above.

> The closure foo::{{closure}} should inherit most attributes applied to the function foo, ...

**Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation.

### Binary Size

I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support.

There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the "right" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction.

### Specialization

There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable, but I also think it should be an easy question to resolve.

### Location only points to the start of a call span

rust-lang#69977 was resolved by rust-lang#73182, and the next step should probably be to [extend `Location` with a notion of the end of a call](rust-lang#73554).

### Regression of std's panic messages

rust-lang#70963 should be resolved by serializing span hygeine to crate metadata: rust-lang#68686.

[2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md
[dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html
[specialization]: rust-lang#70293
[measure-size]: rust-lang#70579
[mitigate-size]: rust-lang#70580
[attr-reference-pr]: rust-lang/reference#742
[wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller
[tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller
[const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs
[diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs
[use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs
[fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs
[trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs
[1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 1, 2020
Stabilize `#[track_caller]`.

# Stabilization Report

RFC: [2091]
Tracking issue: rust-lang#47809

## Summary

From the [rustc-dev-guide chapter][dev-guide]:

> Take this example program:

```rust
fn main() {
    let foo: Option<()> = None;
    foo.unwrap(); // this should produce a useful panic message!
}
```

> Prior to Rust 1.42, panics like this `unwrap()` printed a location in libcore:

```
$ rustc +1.41.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value',...core\macros\mod.rs:15:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
```

> As of 1.42, we get a much more helpful message:

```
$ rustc +1.42.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', example.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

> These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information.

The attribute adds an implicit caller location argument to the ABI of annotated functions, but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator.

## Bottom Line

This PR stabilizes the use of `#[track_caller]` everywhere, including traits and extern blocks. It also stabilizes `core::panic::Location::caller`, although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`.

The implementation for the feature already changed the output of panic messages for a number of std functions, as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44.

## Tests

All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo.

Noteworthy cases:

* [use of attr in std]
  * validates user-facing benefit of the feature
* [trait attribute inheritance]
  * covers subtle behavior designed during implementation and not RFC'd
* [const/codegen equivalence]
  * this was the result of a suspected edge case and investigation
* [diverging function support]
  * covers an unresolved question from the RFC
* [fn pointers and shims]
  * covers important potential sources of unsoundness

## Documentation

The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide].

I have an [open PR to the reference][attr-reference-pr] documenting the attribute.

The intrinsic's [wrapper] includes some examples as well.

## Implementation History

* 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) rust-lang#65037](rust-lang#65037)
  * Picked up the patch that @ayosec had started on the feature gate.
* 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 rust-lang#2/N) rust-lang#65182](rust-lang#65182)
* 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) rust-lang#65258](rust-lang#65258
  * Abandoned approach to send location as a MIR argument.
* 2019-10-28: [`std::panic::Location` is a lang_item, add `core::intrinsics::caller_location` (RFC 2091 3/N) rust-lang#65664](rust-lang#65664)
* 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) rust-lang#65881](rust-lang#65881)
* 2020-01-04: [libstd uses `core::panic::Location` where possible. rust-lang#67137](rust-lang#67137)
* 2020-01-08: [`Option::{expect,unwrap}` and `Result::{expect, expect_err, unwrap, unwrap_err}` have `#[track_caller]` rust-lang#67887](rust-lang#67887)
* 2020-01-20: [Fix #[track_caller] and function pointers rust-lang#68302](rust-lang#68302) (fixed rust-lang#68178)
* 2020-03-23: [#[track_caller] in traits rust-lang#69251](rust-lang#69251)
* 2020-03-24: [#[track_caller] on core::ops::{Index, IndexMut}. rust-lang#70234](rust-lang#70234)
* 2020-04-08 [Support `#[track_caller]` on functions in `extern "Rust" { ... }` rust-lang#70916](rust-lang#70916)

## Unresolveds

### From the RFC

> Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing
> measure.

**Resolved.** See the dev-guide documentation and the tests section above.

> Diverging functions should be supported.

**Resolved.** See the tests section above.

> The closure foo::{{closure}} should inherit most attributes applied to the function foo, ...

**Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation.

### Binary Size

I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support.

There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the "right" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction.

### Specialization

There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable, but I also think it should be an easy question to resolve.

### Location only points to the start of a call span

rust-lang#69977 was resolved by rust-lang#73182, and the next step should probably be to [extend `Location` with a notion of the end of a call](rust-lang#73554).

### Regression of std's panic messages

rust-lang#70963 should be resolved by serializing span hygeine to crate metadata: rust-lang#68686.

[2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md
[dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html
[specialization]: rust-lang#70293
[measure-size]: rust-lang#70579
[mitigate-size]: rust-lang#70580
[attr-reference-pr]: rust-lang/reference#742
[wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller
[tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller
[const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs
[diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs
[use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs
[fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs
[trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs
[1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 1, 2020
Stabilize `#[track_caller]`.

# Stabilization Report

RFC: [2091]
Tracking issue: rust-lang#47809

## Summary

From the [rustc-dev-guide chapter][dev-guide]:

> Take this example program:

```rust
fn main() {
    let foo: Option<()> = None;
    foo.unwrap(); // this should produce a useful panic message!
}
```

> Prior to Rust 1.42, panics like this `unwrap()` printed a location in libcore:

```
$ rustc +1.41.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value',...core\macros\mod.rs:15:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
```

> As of 1.42, we get a much more helpful message:

```
$ rustc +1.42.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', example.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

> These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information.

The attribute adds an implicit caller location argument to the ABI of annotated functions, but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator.

## Bottom Line

This PR stabilizes the use of `#[track_caller]` everywhere, including traits and extern blocks. It also stabilizes `core::panic::Location::caller`, although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`.

The implementation for the feature already changed the output of panic messages for a number of std functions, as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44.

## Tests

All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo.

Noteworthy cases:

* [use of attr in std]
  * validates user-facing benefit of the feature
* [trait attribute inheritance]
  * covers subtle behavior designed during implementation and not RFC'd
* [const/codegen equivalence]
  * this was the result of a suspected edge case and investigation
* [diverging function support]
  * covers an unresolved question from the RFC
* [fn pointers and shims]
  * covers important potential sources of unsoundness

## Documentation

The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide].

I have an [open PR to the reference][attr-reference-pr] documenting the attribute.

The intrinsic's [wrapper] includes some examples as well.

## Implementation History

* 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) rust-lang#65037](rust-lang#65037)
  * Picked up the patch that @ayosec had started on the feature gate.
* 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 rust-lang#2/N) rust-lang#65182](rust-lang#65182)
* 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) rust-lang#65258](rust-lang#65258
  * Abandoned approach to send location as a MIR argument.
* 2019-10-28: [`std::panic::Location` is a lang_item, add `core::intrinsics::caller_location` (RFC 2091 3/N) rust-lang#65664](rust-lang#65664)
* 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) rust-lang#65881](rust-lang#65881)
* 2020-01-04: [libstd uses `core::panic::Location` where possible. rust-lang#67137](rust-lang#67137)
* 2020-01-08: [`Option::{expect,unwrap}` and `Result::{expect, expect_err, unwrap, unwrap_err}` have `#[track_caller]` rust-lang#67887](rust-lang#67887)
* 2020-01-20: [Fix #[track_caller] and function pointers rust-lang#68302](rust-lang#68302) (fixed rust-lang#68178)
* 2020-03-23: [#[track_caller] in traits rust-lang#69251](rust-lang#69251)
* 2020-03-24: [#[track_caller] on core::ops::{Index, IndexMut}. rust-lang#70234](rust-lang#70234)
* 2020-04-08 [Support `#[track_caller]` on functions in `extern "Rust" { ... }` rust-lang#70916](rust-lang#70916)

## Unresolveds

### From the RFC

> Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing
> measure.

**Resolved.** See the dev-guide documentation and the tests section above.

> Diverging functions should be supported.

**Resolved.** See the tests section above.

> The closure foo::{{closure}} should inherit most attributes applied to the function foo, ...

**Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation.

### Binary Size

I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support.

There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the "right" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction.

### Specialization

There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable, but I also think it should be an easy question to resolve.

### Location only points to the start of a call span

rust-lang#69977 was resolved by rust-lang#73182, and the next step should probably be to [extend `Location` with a notion of the end of a call](rust-lang#73554).

### Regression of std's panic messages

rust-lang#70963 should be resolved by serializing span hygeine to crate metadata: rust-lang#68686.

[2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md
[dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html
[specialization]: rust-lang#70293
[measure-size]: rust-lang#70579
[mitigate-size]: rust-lang#70580
[attr-reference-pr]: rust-lang/reference#742
[wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller
[tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller
[const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs
[diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs
[use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs
[fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs
[trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs
[1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 1, 2020
Stabilize `#[track_caller]`.

# Stabilization Report

RFC: [2091]
Tracking issue: rust-lang#47809

## Summary

From the [rustc-dev-guide chapter][dev-guide]:

> Take this example program:

```rust
fn main() {
    let foo: Option<()> = None;
    foo.unwrap(); // this should produce a useful panic message!
}
```

> Prior to Rust 1.42, panics like this `unwrap()` printed a location in libcore:

```
$ rustc +1.41.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value',...core\macros\mod.rs:15:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
```

> As of 1.42, we get a much more helpful message:

```
$ rustc +1.42.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', example.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

> These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information.

The attribute adds an implicit caller location argument to the ABI of annotated functions, but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator.

## Bottom Line

This PR stabilizes the use of `#[track_caller]` everywhere, including traits and extern blocks. It also stabilizes `core::panic::Location::caller`, although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`.

The implementation for the feature already changed the output of panic messages for a number of std functions, as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44.

## Tests

All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo.

Noteworthy cases:

* [use of attr in std]
  * validates user-facing benefit of the feature
* [trait attribute inheritance]
  * covers subtle behavior designed during implementation and not RFC'd
* [const/codegen equivalence]
  * this was the result of a suspected edge case and investigation
* [diverging function support]
  * covers an unresolved question from the RFC
* [fn pointers and shims]
  * covers important potential sources of unsoundness

## Documentation

The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide].

I have an [open PR to the reference][attr-reference-pr] documenting the attribute.

The intrinsic's [wrapper] includes some examples as well.

## Implementation History

* 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) rust-lang#65037](rust-lang#65037)
  * Picked up the patch that @ayosec had started on the feature gate.
* 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 rust-lang#2/N) rust-lang#65182](rust-lang#65182)
* 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) rust-lang#65258](rust-lang#65258
  * Abandoned approach to send location as a MIR argument.
* 2019-10-28: [`std::panic::Location` is a lang_item, add `core::intrinsics::caller_location` (RFC 2091 3/N) rust-lang#65664](rust-lang#65664)
* 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) rust-lang#65881](rust-lang#65881)
* 2020-01-04: [libstd uses `core::panic::Location` where possible. rust-lang#67137](rust-lang#67137)
* 2020-01-08: [`Option::{expect,unwrap}` and `Result::{expect, expect_err, unwrap, unwrap_err}` have `#[track_caller]` rust-lang#67887](rust-lang#67887)
* 2020-01-20: [Fix #[track_caller] and function pointers rust-lang#68302](rust-lang#68302) (fixed rust-lang#68178)
* 2020-03-23: [#[track_caller] in traits rust-lang#69251](rust-lang#69251)
* 2020-03-24: [#[track_caller] on core::ops::{Index, IndexMut}. rust-lang#70234](rust-lang#70234)
* 2020-04-08 [Support `#[track_caller]` on functions in `extern "Rust" { ... }` rust-lang#70916](rust-lang#70916)

## Unresolveds

### From the RFC

> Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing
> measure.

**Resolved.** See the dev-guide documentation and the tests section above.

> Diverging functions should be supported.

**Resolved.** See the tests section above.

> The closure foo::{{closure}} should inherit most attributes applied to the function foo, ...

**Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation.

### Binary Size

I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support.

There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the "right" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction.

### Specialization

There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable, but I also think it should be an easy question to resolve.

### Location only points to the start of a call span

rust-lang#69977 was resolved by rust-lang#73182, and the next step should probably be to [extend `Location` with a notion of the end of a call](rust-lang#73554).

### Regression of std's panic messages

rust-lang#70963 should be resolved by serializing span hygeine to crate metadata: rust-lang#68686.

[2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md
[dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html
[specialization]: rust-lang#70293
[measure-size]: rust-lang#70579
[mitigate-size]: rust-lang#70580
[attr-reference-pr]: rust-lang/reference#742
[wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller
[tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller
[const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs
[diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs
[use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs
[fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs
[trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs
[1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-specialization Area: Trait impl specialization F-specialization `#![feature(specialization)]` F-track_caller `#![feature(track_caller)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants