-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Make feature key optional for rustc_stable, rustc_const_stable attributes #88588
Conversation
r? @wesleywiser (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
4e11681
to
4336cca
Compare
Updated rustdoc & clippy, maybe now the failure I was seeing will pop up here. Although I'm not seeing it anymore myself after commenting out |
…utes … so partial stabilizations no longer have to make up a feature name that never existed as unstable for the stabilized subset of the API.
4336cca
to
bf8a53e
Compare
@@ -12,6 +12,7 @@ | |||
#![feature(crate_visibility_modifier)] | |||
#![feature(never_type)] | |||
#![feature(once_cell)] | |||
#![feature(option_result_contains)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just noticed I left this in but removed the use of Option::contains
. Will remove with the next push.
I'm not sure what this will achieve. Unstable feature names are unstable. Feature names changing or changing meaning happens regularly, not only during partial stabilizations. We reguarly change the api of something during stabilization. Then it does use the same name as an unstable feature before, but the api is different, so it gets blurry whether that's the same feature as before or not. Sometimes features get split and stay unstable for a while, so the old feature name disappears completely. Sometimes features get renamed or split, unstably, but then later stabilized in the same version, which means that there was never a 'release' in which it was named like that. Sometimes we stabilize most of something, and keep the feature name for the stabilized feature, and rename the feature of the remaining unstable ones. If you want to work towards more stable 'unsteable feature names', I don't think this will help much. And even for that purpose, it might even be good to give every stable feature a name, even if that name has not appeared as unstable before. Then you can at least talk about 'the first rust version that had |
The job Click to see the possible cause of the failure (guessed by this bot)
|
I think this achieves:
Since we're talking about library features, not language features here, where would this identifier be any clearer than the item name? I'd say "the first rust version that had |
☔ The latest upstream changes (presumably #80522) made this pull request unmergeable. Please resolve the merge conflicts. |
One more thing that would be simplified: New trait impls (which are always insta-stable) for which authors would no longer have to make up a meaningless feature name. ping @wesleywiser @m-ou-se what do I do to move this forwards (towards a decision on whether this changes makes sense or not)? Open an MCP? |
This feels to me like a question for the libs team. I'm not sure what processes they use but bumping that Zulip thread would probably be a good idea. I'm happy to review the implementation once they've signed off on the feature design. |
(Waiting on T-libs) |
I posted to the Zulip thread again on Oct 6, but got no responses. Is this going to be discussed? |
This was discussed in the library team meeting last week. Our conclusion was that we don't think this change really solves much, while it does make it easier to make the mistake of not having a feature name in cases where we do want it. We also do not want to give the impression that unstable feature names are something 'stable' that can be tracked and doesn't change meaning over time. |
What does it mean that this is now |
I didn't close it yet because I wanted to make there's space for you to respond. But unless you have new arguments to change opinions here, this should probably be closed, yes. |
… so partial stabilizations no longer have to make up a feature name that never existed as unstable for the stabilized subset of the API.
This seems to break at runtime, presumably because the on-disk representation of the affected
rustc_attr
types changed. Not sure how to proceed here. If sbd. could give me a hint about how this could be made to work that would be appreciated.Brief Zulip thread about this: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.60feature.60.20key.20in.20rustc_stable.20and.20rustc_const_stable