Rollup of 7 pull requests
Successful merges:
- #68984 (Make `u8::is_ascii` a stable `const fn`)
- #69339 (Add test for #69312)
- #69346 (Clean up E0323, E0324, E0325 and E0326 explanations)
- #69348 (Wrong error message for move_ref_pattern)
- #69349 (MIR is not an experiment anymore)
- #69354 (Test `Duration::new` panics on overflow)
- #69370 (move const_eval.rs into the module folder)
Failed merges:
r? @ghost
Wrong error message for move_ref_pattern
The current error message states that move occurs *because of `Copy`*:
```Rust
"move occurs because `{}` has type `{}` which does implement the `Copy` trait."
```
I found this randomly when surfing through the sources. This means, I don't have any context and might be completely wrong.
r? @Centril
Make `u8::is_ascii` a stable `const fn`
`char::is_ascii` was already stabilized as `const fn` in #55278, so there is no reason for `u8::is_ascii` to go through an unstable period.
cc @rust-lang/libs
All of these functions can be implemented simply and naturally as
const functions, e.g. u32::from_le_bytes can be implemented as
(bytes[0] as u32)
| (bytes[1] as u32) << 8
| (bytes[2] as u32) << 16
| (bytes[3] as u32) << 24
So stabilizing the constness will not expose that internally they are
implemented using transmute which is not const in stable.
Revert #69280Resolves#69313 by reverting #69280.
After #69280, `#[rustc_args_required_const(2)]` is required on the declaration of `simd_shuffle` intrinsics. This is allowed breakage, since you can't define platform intrinsics on stable. However, the latest release of the widely used `packed_simd` crate defines these intrinsics without the requisite attribute. Since there's no urgency to merge #69280, let's revert it. We can reconsider when rust-lang/packed_simd#278 is included in a point release of `packed_simd`.
r? @petrochenkov
Tweak binding lifetime suggestion text
We already have a structured suggestion, but the wording made it seem like that wasn't the case.
Fix#65286. r? @varkor
Unify and improve const-prop lints
Add a single helper method for all lints emitted by const-prop, and make that lint different from the CTFE `const_err` lint. Also consistently check overflow on *arithmetic*, not on the assertion, to make behavior the same for debug and release builds.
See [this summary comment](https://github.com/rust-lang/rust/pull/69185#issuecomment-587924754) for details and the latest status.
In terms of lint formatting, I went for what seems to be the better style: have a general message above the code, and then a specific message at the span:
```
error: this arithmetic operation will overflow
--> $DIR/const-err2.rs:21:18
|
LL | let a_i128 = -std::i128::MIN;
| ^^^^^^^^^^^^^^^ attempt to negate with overflow
```
We could also just have the specific message above and no text at the span if that is preferred.
I also converted some of the existing tests to use compiletest revisions, so that the same test can check a bunch of different compile flags.
Fixes https://github.com/rust-lang/rust/issues/69020.
Helps with https://github.com/rust-lang/rust/issues/69021: debug/release are now consistent, but the assoc-const test in that issue still fails (there is a FIXME in the PR for this). The reason seems to be that const-prop notices the assoc const in `T::N << 42` and does not even bother calling `const_prop` on that operation.
Has no effect on https://github.com/rust-lang/rust/issues/61821; the duplication there has entirely different reasons.
#69148 has a proper fix, but it is too big to backport.
This change avoids the ICE by actually emitting an appropriate error. The
output will be duplicated in some cases, but that's better than the
avoidable ICE.
