Tracking Issue for const_caller_location
ArekPiekarz opened this issue · 16 comments
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
- Implement the RFC
- Adjust documentation (see instructions on rustc-dev-guide)
- Stabilization PR (see instructions on rustc-dev-guide)
Unresolved Questions
Implementation history
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.
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 Location::caller would be incredibly valuable for tokio-rs/tracing, as it'd allow tracing to get rid of some pretty gnarly macros.
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 'static from Subscribers. tracing 0.2 might loosen this requirement to use Cow under the hood, but I'm not sure when that will happen.
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.
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 Location.
🔔 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.
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 ;-;