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

Allow multiple #[unstable] attributes on one item #94770

Open
m-ou-se opened this issue Mar 9, 2022 · 3 comments · May be fixed by #131824
Open

Allow multiple #[unstable] attributes on one item #94770

m-ou-se opened this issue Mar 9, 2022 · 3 comments · May be fixed by #131824
Assignees
Labels
A-stability Area: `#[stable]`, `#[unstable]` etc. C-feature-request Category: A feature request, i.e: not implemented / a PR. E-help-wanted Call for participation: Help is requested to fix this issue. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. F-staged_api `#![feature(staged_api)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@m-ou-se
Copy link
Member

m-ou-se commented Mar 9, 2022

We sometimes have things that should be gated by multiple features. E.g. ScopedJoinHandle::is_running is part of scoped_threads, but also of thread_is_running. In these cases we now just apply only one of the #[unstable] attributes, and because of that sometimes accidentally stabilize something when only one of the features gets stabilized.

It'd be great if we could add multiple #[unstable] attributes to a single item. Allowing multiple #[stable] tags isn't a necessity. We could just remove the #[unstable] tag if the feature gets stabilized and there are other #[unstable] tags left. The most important part is that we don't forget about the other unstable tags and don't stabilize something by accident.

Another option would be multiple feature = arguments to #[unstable].

@m-ou-se m-ou-se added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. E-help-wanted Call for participation: Help is requested to fix this issue. labels Mar 9, 2022
@compiler-errors
Copy link
Member

@rustbot claim

@compiler-errors compiler-errors removed their assignment Nov 5, 2022
@compiler-errors compiler-errors added the E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. label Nov 5, 2022
@Enselic Enselic added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Dec 3, 2023
@dianne
Copy link
Contributor

dianne commented Sep 17, 2024

I'd like to try picking this back up. Since it's been a while, would the desired design still be the same? Keeping the behavior of the old PR, I think this would allow potentially multiple #[unstable] attributes per item, but at most one #[stable], with no mixing of #[stable] and #[unstable] (and likewise for #[rustc_const_unstable]/#[rustc_const_stable]).
I'm assuming #[rustc_default_body_unstable] should also be able to depend on multiple features in the same way.

@dianne
Copy link
Contributor

dianne commented Oct 4, 2024

@rustbot claim

@dianne dianne linked a pull request Oct 17, 2024 that will close this issue
@fmease fmease added the F-staged_api `#![feature(staged_api)]` label Dec 14, 2024
@fmease fmease added C-feature-request Category: A feature request, i.e: not implemented / a PR. A-stability Area: `#[stable]`, `#[unstable]` etc. and removed C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Dec 14, 2024
@Noratrieb Noratrieb marked this as a duplicate of #134319 Dec 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-stability Area: `#[stable]`, `#[unstable]` etc. C-feature-request Category: A feature request, i.e: not implemented / a PR. E-help-wanted Call for participation: Help is requested to fix this issue. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. F-staged_api `#![feature(staged_api)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
5 participants