-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Tracking Issue for const_caller_location #76156
Comments
I wasn't sure if there was anything else needed to fully implement the RFC for const, but I preferred to stay on the safe side and left it unchecked when creating this issue. |
…racking_issue, r=joshtriplett Update tracking issue for const_caller_location Update the tracking issue to rust-lang#76156, as suggested in rust-lang#76105.
…racking_issue, r=joshtriplett Update tracking issue for const_caller_location Update the tracking issue to rust-lang#76156, as suggested in rust-lang#76105.
…cking_issue, r=joshtriplett Update tracking issue for const_caller_location Update the tracking issue to rust-lang#76156, as suggested in rust-lang#76105.
Out of curiosity, are there any blockers to this being stabilized, other than getting meaningful feedback on its current state? I ask because a stable, const |
Visiting for T-compiler steering backlog bonanza. We believe this feature will be most useful in concert with PR #101030. But the latter has not been merged yet. So we're going to treat this as "needs to bake", and after PR #101030 has gotten some exercise in the wild, then we can talk about stabilizing them as a set. @rustbot label: S-tracking-needs-to-bake |
@davidbarsky out of curiosity, does tracing need #101030 to be stabilized as well or just this feature? |
To put @wesleywiser 's note above in other words: there is the question of whether #102911 should be merged in with this tracking issue. That's basically a question of whether this functionality is sufficiently useful on its own, without the ability to observe Location fields, that it would be worth stabilizing #76156 without stabilizing #102911. |
@wesleywiser @pnkfelix sorry for the delay in responding! This post was sitting unpublished in my tabs 😓. Anyways: tracing will need #102911 in addition to #76156 because Metadata has a de-facto requirement to be |
This has baked for a while now and hasn't lit any fires. Can we get this on track for stabilisation? |
Bump |
Libs-api is happy to to stabilize this, but we would like to check with @rust-lang/wg-const-eval first. |
I don't see any issues with this. The impl has been tried and tested on the miri side extensively. |
@rfcbot fcp merge |
Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members: 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. |
To be clear, this FCP is intended to also cover #102911 which const-stabilizes the other methods on |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
…ields, r=dtolnay Stabilize `const_caller_location` and `const_location_fields` Closes rust-lang#102911. Closes rust-lang#76156. tests: [library/core/tests/panic/location.rs](https://github.com/rust-lang/rust/blob/3521a2f2f317cb978063842485c7d1bc86ec82b6/library/core/tests/panic/location.rs) API: ```rust // core::panic::location impl Location { pub const fn caller() -> &'static Location<'static>; pub const fn file(&self) -> &str; pub const fn line(&self) -> u32; pub const fn column(&self) -> u32; } ```
…ields, r=dtolnay Stabilize `const_caller_location` and `const_location_fields` Closes rust-lang#102911. Closes rust-lang#76156. tests: [library/core/tests/panic/location.rs](https://github.com/rust-lang/rust/blob/3521a2f2f317cb978063842485c7d1bc86ec82b6/library/core/tests/panic/location.rs) API: ```rust // core::panic::location impl Location { pub const fn caller() -> &'static Location<'static>; pub const fn file(&self) -> &str; pub const fn line(&self) -> u32; pub const fn column(&self) -> u32; } ```
…ields, r=dtolnay Stabilize `const_caller_location` and `const_location_fields` Closes rust-lang#102911. Closes rust-lang#76156. tests: [library/core/tests/panic/location.rs](https://github.com/rust-lang/rust/blob/3521a2f2f317cb978063842485c7d1bc86ec82b6/library/core/tests/panic/location.rs) API: ```rust // core::panic::location impl Location { pub const fn caller() -> &'static Location<'static>; pub const fn file(&self) -> &str; pub const fn line(&self) -> u32; pub const fn column(&self) -> u32; } ```
Rollup merge of rust-lang#122291 - lilasta:stabilize_const_location_fields, r=dtolnay Stabilize `const_caller_location` and `const_location_fields` Closes rust-lang#102911. Closes rust-lang#76156. tests: [library/core/tests/panic/location.rs](https://github.com/rust-lang/rust/blob/3521a2f2f317cb978063842485c7d1bc86ec82b6/library/core/tests/panic/location.rs) API: ```rust // core::panic::location impl Location { pub const fn caller() -> &'static Location<'static>; pub const fn file(&self) -> &str; pub const fn line(&self) -> u32; pub const fn column(&self) -> u32; } ```
Yipee, when is this getting stabilized? :D Edit: Nvm I can see it on the nightly docs that it is 1.79, maybe I should go read up on what final comment period means ;-; |
This is a tracking issue for the const part of RFC 2091: track_caller (rust-lang/rfcs#2091).
The feature gate for the issue is
#![feature(const_caller_location)]
.About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Unresolved Questions
Implementation history
#72445
The text was updated successfully, but these errors were encountered: