Conversation
|
@alexcrichton what you think? |
src/librustc/metadata/creader.rs
Outdated
There was a problem hiding this comment.
This overloads the meaning of [feature(staged_api)] in a way which is really confusing; feature attributes aren't supposed to have any semantic meaning. On master, [feature(staged_api)] means "allow the use of unstable attributes related to staged APIs". [staged_api] means "apply stability rules to users of this crate".
Granted, the distinction is sort of useless at the moment, but we could, for example, decide that we shouldn't serialize feature attributes in the crate metadata because they don't affect users of a crate, or add [feature(all)] to turn off feature gate checking for a crate.
|
I think it's fine to remove the attribute, but I agree with @eefriedman that the detection here may be a little off. I would suspect that the |
|
I don't see how I can remove the metadata part without bringing |
|
Hm that's a good point, but perhaps that's not a question the compiler should be asking? For example rather than querying "is this crate a staged_api" crate it could query "is this crate an unstable crate"? Either that or "is this crate a staged_api" crate can be answered by "is there a stable or unstable attribute at the crate root" perhaps. |
That's certainly possible, the only problem is that crate root annotations are enforced only in staged_api crates. They are pretty easy to forget as #29083 showed. A compromise variant - staged-ness is determined by stable/unstable in the crate root, crate root annotations are required when |
|
How about a slight variant of that: it's an error to annotate anything in a crate which isn't itself annotated, regardless of the presence of |
|
Sounds good. |
|
Seems ok. @bors r+ |
|
📌 Commit 4b80784 has been approved by |
Depends on #30015 since this branch includes `#[staged_api]` changes.
Closes #30008
#[stable],#[unstable]and#[rustc_deprecated]are now guarded by#[feature(staged_api)]r? @brson