Document #[track_caller]. #742
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for the PR. What is the context for this change? The reference only documents stable attributes, and AFAIK this is still unstable. Will it be stabilized soon? |
Centril
added
the
S-waiting-on-stabilization
Centril
reviewed
Feb 3, 2020
Ah -- right! I'm documenting the attribute here based on feedback in rust-lang/rust#47809 (comment) while I'm working on overall feature docs for the rustc-guide. Perhaps I should hold off on this PR until closer to stabilization? |
The PR won't be merged until this has been stabilized upstream in rustc, but feel free to polish the section meanwhile. It's certainly better to have the docs ready to go as opposed to having a bunch of work much after stabilization. ;) It's also useful for the eventual stabilization report. |
Centril
reviewed
Feb 10, 2020
3 tasks
anp
commented
Mar 21, 2020
nikomatsakis
reviewed
Apr 6, 2020
There was a problem hiding this comment.
Hmm so my take on this PR is that it could say a bit more. Here are a few items:
- Where can you put this attribute? From my understanding, the answer is basically "any function", but there are some cases worth discussing, most notably:
- Trait definition, and the fact that the attribute is "inherited" by impls
- I think we should link to the stable function in the standard library that is able to obtain
Locationinfo (mentioning the intrinsic, as we do, is also good). I agree with the suggestion to rework the description of when we are able to get caller information so that it talks about the stack explicitly -- it seems fine to say that things work "as if" we walk up the stack. We should probably also say that this kind of information is always a "hint" and that implementations are not required to preserve it (and that rustc in particular fails to preserve it across virtual calls).
|
(Looking back, I realize that most the things I listed were actually already marked as TODO by @anp, so I guess "seems good" =) |
|
OK, I think I've addressed the outstanding feedback, ready for more! |
nikomatsakis
approved these changes
Jun 11, 2020
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
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 pull request
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 pull request
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 pull request
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 pull request
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
|
rust-lang/rust@ae79c30 has landed so AIUI this is ready to as well. Or is it preferred to wait for a nightly release including the PR? |
ehuss
added
S-needs-reviewer
|
@anp would you be able to add a small example? It doesn't need to be complicated, just a basic usage of placing the attribute on a function and calling Also, I'm wondering if "codegen" is the right chapter to put this in. Is there any particular reason you placed it there? Generally my intent is that section is for things that influence how LLVM operates. But my understanding of track_caller is that its support is injected into MIR, right? I don't really know how this is implemented, but I'm guessing it changes the Rust ABI to pass the location along? Would "runtime" make more sense since this is related to panic handling? Or ABI (if that's how it works)? Hm, none of these seem like a really good fit... |
|
Good call adding an example. LMK what you think of the ones I included, I just built off of the existing prose examples. The attribute is mostly implemented in the codegen portions of the compiler, although I agree that runtime and/or ABI seem like good options too. Let me know where you'd like it? |
|
Thanks! I guess it is ok to keep it in the codegen section for now. If a better organization presents itself in the future, we can always move things around later. I'd like to get one other person to do a quick review before merging. I'm going to randomly ping @joshtriplett, can you take a quick look at this to double-check it makes sense? |
|
Looks good to me. |
|
Ok, thanks @anp and @joshtriplett! |
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jul 22, 2020
Update books ## reference 5 commits in 0ea7bc494f1289234d8800bb9185021e0ad946f0..b329ce37424874ad4db94f829a55807c6e21d2cb 2020-07-02 15:33:04 -0700 to 2020-07-20 08:54:08 -0700 - this '*' is unnecessary, and reduces readability (rust-lang/reference#853) - Tiny typo fix (rust-lang/reference#849) - Update const eval chapter to latest changes (rust-lang/reference#842) - Document #[track_caller]. (rust-lang/reference#742) - Document shebang restriction. (rust-lang/reference#823) ## book 2 commits in 84a31397b34f9d405df44f2899ff17a4828dba18..a914f2c7e5cdb771fa465de142381a51c53b580e 2020-07-04 10:50:18 -0500 to 2020-07-21 09:20:05 -0500 - Change misleading wording (rust-lang/book#2399) - Improve wording to include Windows versions (rust-lang/book#2395) ## edition-guide 3 commits in 82bec5877c77cfad530ca11095db4456d757f668..bd6e4a9f59c5c1545f572266af77f5c7a5bad6d1 2020-06-03 08:56:02 -0500 to 2020-07-12 17:37:08 -0500 - update guide for 1.36 and 1.37 (rust-lang/edition-guide#217) - Add contents for Rust 1.35 (rust-lang/edition-guide#216) - update edition guide for Rust 1.34 (rust-lang/edition-guide#215)
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jul 22, 2020
Update books ## reference 5 commits in 0ea7bc494f1289234d8800bb9185021e0ad946f0..b329ce37424874ad4db94f829a55807c6e21d2cb 2020-07-02 15:33:04 -0700 to 2020-07-20 08:54:08 -0700 - this '*' is unnecessary, and reduces readability (rust-lang/reference#853) - Tiny typo fix (rust-lang/reference#849) - Update const eval chapter to latest changes (rust-lang/reference#842) - Document #[track_caller]. (rust-lang/reference#742) - Document shebang restriction. (rust-lang/reference#823) ## book 2 commits in 84a31397b34f9d405df44f2899ff17a4828dba18..a914f2c7e5cdb771fa465de142381a51c53b580e 2020-07-04 10:50:18 -0500 to 2020-07-21 09:20:05 -0500 - Change misleading wording (rust-lang/book#2399) - Improve wording to include Windows versions (rust-lang/book#2395) ## edition-guide 3 commits in 82bec5877c77cfad530ca11095db4456d757f668..bd6e4a9f59c5c1545f572266af77f5c7a5bad6d1 2020-06-03 08:56:02 -0500 to 2020-07-12 17:37:08 -0500 - update guide for 1.36 and 1.37 (rust-lang/edition-guide#217) - Add contents for Rust 1.35 (rust-lang/edition-guide#216) - update edition guide for Rust 1.34 (rust-lang/edition-guide#215)
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jul 22, 2020
Update books ## reference 5 commits in 0ea7bc494f1289234d8800bb9185021e0ad946f0..b329ce37424874ad4db94f829a55807c6e21d2cb 2020-07-02 15:33:04 -0700 to 2020-07-20 08:54:08 -0700 - this '*' is unnecessary, and reduces readability (rust-lang/reference#853) - Tiny typo fix (rust-lang/reference#849) - Update const eval chapter to latest changes (rust-lang/reference#842) - Document #[track_caller]. (rust-lang/reference#742) - Document shebang restriction. (rust-lang/reference#823) ## book 2 commits in 84a31397b34f9d405df44f2899ff17a4828dba18..a914f2c7e5cdb771fa465de142381a51c53b580e 2020-07-04 10:50:18 -0500 to 2020-07-21 09:20:05 -0500 - Change misleading wording (rust-lang/book#2399) - Improve wording to include Windows versions (rust-lang/book#2395) ## edition-guide 3 commits in 82bec5877c77cfad530ca11095db4456d757f668..bd6e4a9f59c5c1545f572266af77f5c7a5bad6d1 2020-06-03 08:56:02 -0500 to 2020-07-12 17:37:08 -0500 - update guide for 1.36 and 1.37 (rust-lang/edition-guide#217) - Add contents for Rust 1.35 (rust-lang/edition-guide#216) - update edition guide for Rust 1.34 (rust-lang/edition-guide#215)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.