rust-lang/rust
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
51b51b51d7931da85280382a81c4dd80c73ca754
rust/tests/ui/borrowck/issue-64453.stderr

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

26 lines
1.1 KiB
Plaintext
Raw Normal View History

Note def descr in NonConstFunctionCall
2024-12-23 21:49:48 +00:00
error[E0015]: cannot call non-const function `format` in statics
regression test for 64453 borrow check error.
2019-09-30 11:05:04 +02:00
--> $DIR/issue-64453.rs:4:31
|
LL | static settings_dir: String = format!("");
| ^^^^^^^^^^^
|
bless you
2021-12-10 01:10:05 +08:00
= note: calls in statics are limited to constant functions, tuple structs and tuple variants
Stabilize `LazyCell` and `LazyLock` (`lazy_cell`)
2024-02-20 20:55:13 -07:00
= note: consider wrapping this expression in `std::sync::LazyLock::new(|| ...)`
Show macro name in 'this error originates in macro' message When there are multiple macros in use, it can be difficult to tell which one was responsible for producing an error.
2021-02-13 14:52:25 -05:00
= note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info)
regression test for 64453 borrow check error.
2019-09-30 11:05:04 +02:00
Stop sorting bodies by span. The definition order is already close to the span order, and only differs in corner cases.
2021-07-16 16:54:47 +02:00
error[E0507]: cannot move out of static item `settings_dir`
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
--> $DIR/issue-64453.rs:13:37
Stop sorting bodies by span. The definition order is already close to the span order, and only differs in corner cases.
2021-07-16 16:54:47 +02:00
|
LL | let settings_data = from_string(settings_dir);
| ^^^^^^^^^^^^ move occurs because `settings_dir` has type `String`, which does not implement the `Copy` trait
Suggest `.clone()` in some move errors ``` error[E0507]: cannot move out of `*x` which is behind a shared reference --> $DIR/borrowck-fn-in-const-a.rs:6:16 | LL | return *x | ^^ move occurs because `*x` has type `String`, which does not implement the `Copy` trait | help: consider cloning the value if the performance cost is acceptable | LL - return *x LL + return x.clone() | ```
2024-03-13 03:41:41 +00:00
|
help: consider cloning the value if the performance cost is acceptable
|
LL | let settings_data = from_string(settings_dir.clone());
| ++++++++
Stop sorting bodies by span. The definition order is already close to the span order, and only differs in corner cases.
2021-07-16 16:54:47 +02: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: aborting due to 2 previous errors
regression test for 64453 borrow check error.
2019-09-30 11:05:04 +02:00
Update tests
2020-05-21 12:49:38 -07:00
Some errors have detailed explanations: E0015, E0507.
For more information about an error, try `rustc --explain E0015`.
Reference in New Issue Copy Permalink