Skip to content

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

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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
# for free to join this conversation on GitHub. Already have an account? # 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