-
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
Support multiple unstable attributes on items #94988
Support multiple unstable attributes on items #94988
Conversation
Some changes occurred in src/tools/clippy. cc @rust-lang/clippy Some changes occurred in cc @camelid |
(rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
Hmmmmm. Seems to be an issue with the way that Not exactly sure how to fix this. Any thoughts @Aaron1011 (I think you're familiar with this code, cc #76897)? |
ff62114
to
c44e420
Compare
☔ The latest upstream changes (presumably #95056) made this pull request unmergeable. Please resolve the merge conflicts. |
c44e420
to
16ee185
Compare
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.
Thanks for the PR @compiler-errors.
I took a brief look, everything looks good.
What is the motivation for this PR?
What does it mean for an item to be multiply unstable?
How should it be handled/diagnosed?
I saw you have a specific handling for const-unstable attributes, could you elaborate on that?
} else { | ||
// FIXME(ecstaticmorse); For compatibility, we consider `unstable` callees that | ||
// have no `rustc_const_stable` attributes to be const-unstable as well. This | ||
// should be fixed later. |
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.
Is this compatibility layer still used?
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.
I have no idea. @ecstatic-morse do you know if this FIXME is still valid?
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.
IIRC, these rules proved somewhat contentious, although I don't know if this particular idea was the problematic one. You can take out the FIXME and the "this should be fixed", but please leave the description if it's still correct.
See #94770 for the ask from @m-ou-se who wanted multiple unstable attributes on a single item, I think to avoid accidentally stabilizing it when removing the one unstable flag.
I believe it must be that all unstable features must be enabled or the usage is considered invalid and will be an error. Basically each unstable here is considered independently.
I believe you're referencing the const-call code, which I had to generalize to several unstable attributes. I don't believe this changes behavior for a single const_unstable attribute, but I needed to refactor the code to only pass if all const_unstable attributes were allowed. |
Imagine we have an unstable type called In the past we've had situations where we accidentally stabilized a method like |
16ee185
to
2db02ac
Compare
@rustbot ready I believe this is ready for a more thorough review |
This comment has been minimized.
This comment has been minimized.
2db02ac
to
f732d45
Compare
Some(ConstStability { level: StabilityLevel::Unstable { issue, .. }, feature, .. }) => { | ||
let unstable = if let Some(n) = issue { | ||
Some(ConstStability { level: StabilityLevel::Unstable { unstables, .. }, .. }) => { | ||
// FIXME(compiler-errors): Should we link to several issues here? How? |
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.
cc @jsha who's looked into redesigning rustdoc's version display
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.
@@ -40,7 +41,6 @@ extern crate rustc_ast; | |||
extern crate rustc_ast_lowering; | |||
extern crate rustc_ast_pretty; | |||
extern crate rustc_attr; | |||
extern crate rustc_const_eval; |
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.
Why this change?
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.
I didn't do this intentionally. no idea why that happened, can add it back.
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.
Yeah, I think it should be re-added.
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.
ahh, so I moved is_unstable_const_fn
(which was exported from rustc_const_eval
as a function) to rustc_middle
as a method on TyCtxt
, so there is no dependency on rustc_const_eval
anymore.
In fact, x check rustdoc
fails if I add this crate back:
error: unused extern crate
--> src/librustdoc/lib.rs:44:1
|
44 | extern crate rustc_const_eval;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove it
guess i did do it intentionally, but just forgot about it
f732d45
to
013ac1a
Compare
☔ The latest upstream changes (presumably #95149) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
The implementation looks good overall, left a few nits.
Second question about semantics:
Unstability attributes can be inherited from an enclosing block (examples below). In this implementation, the innermost attribute overrides attributes from outer scopes. I wonder if they should not be made cumulative:
#[rustc_unstable(feature="foo")]
struct Foo {
#[rustc_unstable(feature="bar")]
Bar()
// Is this unstable by ["foo", "bar"] or only ["bar"]?
}
#[rustc_const_unstable(feature="foo")]
impl Foo for () {
#[rustc_const_unstable(feature="bar")]
fn bar() {}
// Is this unstable by ["foo", "bar"] or only ["bar"]?
}
.map(|stab| (stab.level, stab.feature)) | ||
if let Some(rustc_attr::Stability { | ||
level: StabilityLevel::Unstable { unstables, .. }, .. | ||
}) = item.stability(cx.tcx()) | ||
{ |
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.
This block will add the "nightly-only experimental API" message even if there is only the rustc_private
feature. Why this change in behaviour?
.map(|stab| (stab.level, stab.feature)) | ||
if let Some(rustc_attr::Stability { | ||
level: StabilityLevel::Unstable { unstables, .. }, .. | ||
}) = item.stability(cx.tcx()) | ||
{ | ||
let mut message = | ||
"<span class=\"emoji\">🔬</span> This is a nightly-only experimental API.".to_owned(); |
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.
This string and the parentheses could be incorporated to the extra_info.push
below.
@m-ou-se, do you know if we should change the behavior so that the unstable attributes inherited from parent modules are additive? |
Oh, that's a good question. I'd expect them to be additive, but we should take a look at the current |
whoops, I definitely let this PR sit for too long. Let me put it back onto my to-do list.
@m-ou-se, who would be the right person to check this? I can definitely give it a first look-over, but might need some help from T-libs to know what is okay and what might break due to this PR. |
You are not wrong! I'm working on something very closely related in #95956 where I'm adding support for checking the stability of path segments when naming items. This in effect makes them additive and would end up duplicating the functionality in this PR if you added parent module additive inheritance.
Like you said, this seems wrong but we already do this in multiple places, between Based on that and how hard I anticipate auditing the inherited stability attributes to be, I think the right call is to not make them inherit additively in this PR, and instead rely on the stable-in-unstable PR's path segment stability checks to get the additive functionality between parent module stability and item stability. |
This has PR has rotted so much that it probably needs to be re-done from scratch. I'll close this and unclaim the issue. |
This PR started out pretty simple, but ended up being quite a few changes in a lot of different places to support multiple unstable attributes on items.
Please let me know if I should split this up into separate commits. I feel somewhat bad having one mega-commit, but I wrote this kinda all over the place, so I didn't naturally split it up when I was making these changes.
Fixes #94770
cc: @m-ou-se