Skip to content

Remove #[staged_api] #30015

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

Merged
merged 4 commits into from
Nov 26, 2015
Merged

Remove #[staged_api] #30015

merged 4 commits into from
Nov 26, 2015

Conversation

petrochenkov
Copy link
Contributor

Closes #30008

#[stable], #[unstable] and #[rustc_deprecated] are now guarded by #[feature(staged_api)]

r? @brson

@brson
Copy link
Contributor

brson commented Nov 23, 2015

@alexcrichton what you think?

for meta in metas {
if let ast::MetaWord(ref name) = meta.node {
if &name[..] == "staged_api" {
return true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@alexcrichton
Copy link
Member

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 unstable, stable, and rustc_deprecated attributes to all require the staged_api feature gate, and otherwise #![feature(staged_api)] is an unused feature.

@petrochenkov
Copy link
Contributor Author

I don't see how I can remove the metadata part without bringing #[staged_api] back. Crates in the crate store have to determine and report their staged-ness somehow, either through feature or through a separate attribute like staged_api.
(I don't have a strong position on removing or not removing staged_api, but @eefriedman's argument in favor of not removing it looks reasonable)

@alexcrichton
Copy link
Member

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.

@petrochenkov
Copy link
Contributor Author

"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 #[feature(staged_api)] is enabled, i.e. if you want to annotate anything in the crate, then you are gently asked to annotate the crate root as well. This doesn't give #[feature(staged_api)] too much power I guess. @eefriedman what do you think?

@eefriedman
Copy link
Contributor

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 [feature(staged_api)]?

@petrochenkov
Copy link
Contributor Author

Sounds good.
I've updated the PR.

@brson
Copy link
Contributor

brson commented Nov 26, 2015

Seems ok.

@bors r+

@bors
Copy link
Collaborator

bors commented Nov 26, 2015

📌 Commit 4b80784 has been approved by brson

@bors
Copy link
Collaborator

bors commented Nov 26, 2015

⌛ Testing commit 4b80784 with merge 6d88afe...

bors added a commit that referenced this pull request Nov 26, 2015
Closes #30008

`#[stable]`, `#[unstable]` and `#[rustc_deprecated]` are now guarded by `#[feature(staged_api)]`

r? @brson
@bors bors merged commit 4b80784 into rust-lang:master Nov 26, 2015
bors added a commit that referenced this pull request Nov 27, 2015
Depends on #30015 since this branch includes `#[staged_api]` changes.
@petrochenkov petrochenkov deleted the staged branch September 21, 2016 19:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants