rust-lang/rust
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
359bfa901b9d8eddbed7b88b6716dbb77b7bfb95
rust/tests/ui/stability-attribute/missing-const-stability.stderr

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

27 lines
754 B
Plaintext
Raw Normal View History

Require const stability on all stable const items This was supposed to be the case previously, but a missed method call meant that trait impls were not checked.
2021-11-17 21:06:17 -05:00
error: function has missing const stability attribute
Migrate tests to use `-Znext-solver`
2024-06-30 17:08:45 +00:00
--> $DIR/missing-const-stability.rs:7:1
Test for missing const-stability attributes
2020-09-25 13:51:52 -07:00
|
LL | pub const fn foo() {}
Integrate stable feature checking into a query.
2022-01-30 15:41:35 +01:00
| ^^^^^^^^^^^^^^^^^^
Test for missing const-stability attributes
2020-09-25 13:51:52 -07:00
Enforce syntactical stability of const traits in HIR
2025-01-12 20:52:30 +00:00
error: trait has missing const stability attribute
parse `const trait Trait`
2025-07-13 16:49:19 +08:00
--> $DIR/missing-const-stability.rs:23:1
Enforce syntactical stability of const traits in HIR
2025-01-12 20:52:30 +00:00
|
Integrate stable feature checking into a query.
2022-01-30 15:41:35 +01:00
LL | pub const trait Bar {
| ^^^^^^^^^^^^^^^^^^^
Enforce syntactical stability of const traits in HIR
2025-01-12 20:52:30 +00:00
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: function has missing const stability attribute
parse `const trait Trait`
2025-07-13 16:49:19 +08:00
--> $DIR/missing-const-stability.rs:36:1
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
|
LL | pub const unsafe fn size_of_val<T>(x: *const T) -> usize { 42 }
Integrate stable feature checking into a query.
2022-01-30 15:41:35 +01:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
Reword comments and rename HIR visiting methods.
2022-07-03 15:28:57 +02:00
error: associated function has missing const stability attribute
Migrate tests to use `-Znext-solver`
2024-06-30 17:08:45 +00:00
--> $DIR/missing-const-stability.rs:16:5
Reword comments and rename HIR visiting methods.
2022-07-03 15:28:57 +02:00
|
LL | pub const fn foo() {}
Integrate stable feature checking into a query.
2022-01-30 15:41:35 +01:00
| ^^^^^^^^^^^^^^^^^^
Reword comments and rename HIR visiting methods.
2022-07-03 15:28:57 +02:00
Enforce syntactical stability of const traits in HIR
2025-01-12 20:52:30 +00:00
error: aborting due to 4 previous errors
Test for missing const-stability attributes
2020-09-25 13:51:52 -07:00
Reference in New Issue Copy Permalink