replace #[allow_internal_unstable] with #[rustc_allow_const_fn_unstable] for const fns
#78208
Conversation
allow_internal_unstable is currently used to side-step feature gate and stability checks. While it was originally only meant to be used only on macros, its use was expanded to const functions. This commit prepares stricter checks for the usage of allow_internal_unstable (only on macros) and introduces the rustc_allow_const_fn_unstable attribute for usage on functions. See rust-lang#69399
Adds a check to make sure `#[allow_internal_unstable]` can be applied only to macro definitions.
Adds a check to make sure `#[rustc_allow_const_fn_unstable]` can be applied only to functions.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @oli-obk (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
rust-highfive
added
the
S-waiting-on-review
jyn514
added
C-cleanup
|
This is really clean, thanks for taking the care to build clear individual commits |
Recognition for `rustc_allow_const_fn_unstable` attribute was errorneously added in 05f4a9a.
…n rustc_mir Followup rename from 05f4a9a, which introduced `#[rustc_allow_const_fn_unstable]` for `const fn`s.
The validation was introduced in 3a63bf0 without strict validation of functions, e. g. all function types were allowed. Now the validation only allows `const fn`s.
|
Note: If I understood the contributing guide correctly, it is discouraged to change already pushed commits after review (e. g. interactive rebase). Instead it is preferred to add new commits containing the necessary changes, which I did now. If I got that wrong, I'm happy to rebase instead. Edit: It isn't in the documentation, it's directly in rust-highfive's comment to this pr. Sorry for the possible confusion. |
|
The rule is there to make reviewing easier (since in large PRs it can quickly become infeasible to review the entire PR again), but once everything is approved fixing up history is definitely ok. So... I'd r this as it is, though if you want to fix up history, that's totally alright with me, but not neccessary. Please let me know what you prefer |
|
I'd leave it as is this time, because the fix-up commits should be descriptive enough on their own. |
|
@bors r |
|
📌 Commit ac2c599 has been approved by |
bors
added
S-waiting-on-bors
Rollup of 8 pull requests Successful merges: - rust-lang#77984 (Compute proper module parent during resolution) - rust-lang#78085 (MIR validation should check `SwitchInt` values are valid for the type) - rust-lang#78208 (replace `#[allow_internal_unstable]` with `#[rustc_allow_const_fn_unstable]` for `const fn`s) - rust-lang#78209 (Update `compiler_builtins` to 0.1.36) - rust-lang#78276 (Bump backtrace-rs to enable Mach-O support on iOS.) - rust-lang#78320 (Link to cargo's `build-std` feature instead of `xargo` in custom target docs) - rust-lang#78322 (BTreeMap: stop mistaking node::MIN_LEN for a node level constraint) - rust-lang#78326 (Split out statement attributes changes from rust-lang#78306) Failed merges: r? `@ghost`
#[allow_internal_unstable]is currently used to side-step feature gate and stability checks.While it was originally only meant to be used only on macros, its use was expanded to
const fns.This pr adds stricter checks for the usage of
#[allow_internal_unstable](only on macros) and introduces the#[rustc_allow_const_fn_unstable]attribute for usage onconst fns.This pr does not change any of the functionality associated with the use of
#[allow_internal_unstable]on macros or the usage of#[rustc_allow_const_fn_unstable](instead of#[allow_internal_unstable]) onconst fns (see #69399 (comment)).Note: The check for
#[rustc_allow_const_fn_unstable]currently only validates that the attribute is used on a function, because I don't know how I would check if the function is aconst fnat the place of the check. I therefore openend this as a 'draft pull request'.Closes #69399
r? @oli-obk