os-rust/tests/ui/intrinsics/const-eval-select-stability.stderr

error: const function that might be (indirectly) exposed to stable cannot use `#[feature(const_eval_select)]`
  --> $DIR/const-eval-select-stability.rs:17:5
   |
LL |     const_eval_select((), nothing, log);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
help: if the function is not (yet) meant to be exposed to stable, add `#[rustc_const_unstable]` (this is what you probably want to do)
   |
LL + #[rustc_const_unstable(feature = "...", issue = "...")]
LL | pub const fn hey() {
   |
help: otherwise, as a last resort `#[rustc_allow_const_fn_unstable]` can be used to bypass stability checks (this requires team approval)
   |
LL + #[rustc_allow_const_fn_unstable(const_eval_select)]
LL | pub const fn hey() {
   |

error: aborting due to 1 previous error
Re-do recursive const stability checks Fundamentally, we have three disjoint categories of functions: 1. const-stable functions 2. private/unstable functions that are meant to be callable from const-stable functions 3. functions that can make use of unstable const features This PR implements the following system: - `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions. - `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category. - `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls. Also, several holes in recursive const stability checking are being closed. There's still one potential hole that is hard to avoid, which is when MIR building automatically inserts calls to a particular function in stable functions -- which happens in the panic machinery. Those need to not be `rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be sure they follow recursive const stability. But that's a fairly rare and special case so IMO it's fine. The net effect of this is that a `#[unstable]` or unmarked function can be constified simply by marking it as `const fn`, and it will then be const-callable from stable `const fn` and subject to recursive const stability requirements. If it is publicly reachable (which implies it cannot be unmarked), it will be const-unstable under the same feature gate. Only if the function ever becomes `#[stable]` does it need a `#[rustc_const_unstable]` or `#[rustc_const_stable]` marker to decide if this should also imply const-stability. Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to use unstable const lang features (including intrinsics), or (b) `#[stable]` functions that are not yet intended to be const-stable. Adding `#[rustc_const_stable]` is only needed for functions that are actually meant to be directly callable from stable const code. `#[rustc_const_stable_indirect]` is used to mark intrinsics as const-callable and for `#[rustc_const_unstable]` functions that are actually called from other, exposed-on-stable `const fn`. No other attributes are required. 2024-10-06 19:59:19 +02:00			error: const function that might be (indirectly) exposed to stable cannot use `#[feature(const_eval_select)]`
Support unstable moves via stable in unstable items 2022-04-11 18:12:26 -07:00			`--> $DIR/const-eval-select-stability.rs:17:5`
Fix const stability 2021-10-14 06:53:20 +00:00			`\|`
			`LL \| const_eval_select((), nothing, log);`
			`\| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^`
			`\|`
Re-do recursive const stability checks Fundamentally, we have three disjoint categories of functions: 1. const-stable functions 2. private/unstable functions that are meant to be callable from const-stable functions 3. functions that can make use of unstable const features This PR implements the following system: - `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions. - `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category. - `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls. Also, several holes in recursive const stability checking are being closed. There's still one potential hole that is hard to avoid, which is when MIR building automatically inserts calls to a particular function in stable functions -- which happens in the panic machinery. Those need to not be `rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be sure they follow recursive const stability. But that's a fairly rare and special case so IMO it's fine. The net effect of this is that a `#[unstable]` or unmarked function can be constified simply by marking it as `const fn`, and it will then be const-callable from stable `const fn` and subject to recursive const stability requirements. If it is publicly reachable (which implies it cannot be unmarked), it will be const-unstable under the same feature gate. Only if the function ever becomes `#[stable]` does it need a `#[rustc_const_unstable]` or `#[rustc_const_stable]` marker to decide if this should also imply const-stability. Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to use unstable const lang features (including intrinsics), or (b) `#[stable]` functions that are not yet intended to be const-stable. Adding `#[rustc_const_stable]` is only needed for functions that are actually meant to be directly callable from stable const code. `#[rustc_const_stable_indirect]` is used to mark intrinsics as const-callable and for `#[rustc_const_unstable]` functions that are actually called from other, exposed-on-stable `const fn`. No other attributes are required. 2024-10-06 19:59:19 +02:00			help: if the function is not (yet) meant to be exposed to stable, add `#[rustc_const_unstable]` (this is what you probably want to do)
			`\|`
			`LL + #[rustc_const_unstable(feature = "...", issue = "...")]`
			`LL \| pub const fn hey() {`
			`\|`
			help: otherwise, as a last resort `#[rustc_allow_const_fn_unstable]` can be used to bypass stability checks (this requires team approval)
			`\|`
			`LL + #[rustc_allow_const_fn_unstable(const_eval_select)]`
			`LL \| pub const fn hey() {`
			`\|`
Fix const stability 2021-10-14 06:53:20 +00:00
Show number in error message even for one error Co-authored-by: Adrian <adrian.iosdev@gmail.com> 2023-11-21 15:44:16 +00:00			`error: aborting due to 1 previous error`
Fix const stability 2021-10-14 06:53:20 +00:00