Skip to content
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

rustc: do not inherit #[stable] #18887

Merged
merged 2 commits into from
Nov 13, 2014
Merged

Conversation

aturon
Copy link
Member

@aturon aturon commented Nov 11, 2014

This patch tweaks the stability inheritance infrastructure so that
#{stable] attributes are not inherited. Doing so solves two problems:

  1. It allows us to mark module names as stable without accidentally
    marking the items they contain as stable.
  2. It means that a #[stable] attribution must always appear directly
    on the item it applies to, which makes it easier for reviewers to catch
    changes to stable APIs.

Fixes #17484

This patch tweaks the stability inheritance infrastructure so that
`#{stable]` attributes are not inherited. Doing so solves two problems:

1. It allows us to mark module *names* as stable without accidentally
marking the items they contain as stable.

2. It means that a `#[stable]` attribution must always appear directly
on the item it applies to, which makes it easier for reviewers to catch
changes to stable APIs.

Fixes rust-lang#17484
@seanmonstar
Copy link
Contributor

This means I'll need to litter my library with stable attributes when I mark it 1.0?

@aturon
Copy link
Member Author

aturon commented Nov 13, 2014

@seanmonstar The intended use of stability attributes is to give finer-grained control over semver; not everything needs to (or should) be marked stable at a 1.0 release unless you really want to make all of those promises.

In general, the intended approach is to slowly annotate items over time with greater stability, even before 1.0 -- this was what we're doing for the standard library, for example.

By not inheriting #[stable], we remove two kinds of easy mistakes:

  1. If you add an item to an already-stable module, generally that new item should not be immediately stable -- it should likely be experimental. With this approach, it worst it is considered unmarked (which counts as unstable.)
  2. If you are changing a #[stable] API, you always know, because the attribute it local to the item. This makes it easier to catch stability regressions.

Hope that helps. This is definitely something we can tweak over time.

@Gankra
Copy link
Contributor

Gankra commented Nov 13, 2014

Would it be worth considering a #[stable(all)]-type attribute to obtain the old behaviour?

@seanmonstar
Copy link
Contributor

I'm more thinking of smaller libraries with a hand full of methods or structs. One that I'm pretty confident won't change, I'd just stick a #![stable] in lib.rs and commit.

@aturon
Copy link
Member Author

aturon commented Nov 13, 2014

@gankro

Would it be worth considering a #[stable(all)]-type attribute to obtain the old behaviour?

That's what I was going to do at first, but it seemed like overkill. Certainly something we can add. But we definitely want a way to not inherit #[stable] for std.

@seanmonstar

I'm more thinking of smaller libraries with a hand full of methods or structs. One that I'm pretty confident won't change, I'd just stick a #![stable] in lib.rs and commit.

Fair enough. We can take something like @gankro's suggestion if this turns out to be painful in practice.

bors added a commit that referenced this pull request Nov 13, 2014
This patch tweaks the stability inheritance infrastructure so that
`#{stable]` attributes are not inherited. Doing so solves two problems:

1. It allows us to mark module *names* as stable without accidentally
marking the items they contain as stable.

2. It means that a `#[stable]` attribution must always appear directly
on the item it applies to, which makes it easier for reviewers to catch
changes to stable APIs.

Fixes #17484
@bors bors closed this Nov 13, 2014
@bors bors merged commit 8352195 into rust-lang:master Nov 13, 2014
lnicola pushed a commit to lnicola/rust that referenced this pull request Jan 20, 2025
…ompletions_tests

refactor test helpers within ide-completions
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.

Cannot mark only the name of a module as stable
5 participants