Fix inaccurate `std::intrinsics::simd` documentation
This addresses two issues:
- the docs on comparison operators (`simd_gt` etc.) said they only work for floating-point vectors, but they work for integer vectors too.
- the docs on various functions that use a mask did not document that the mask must be a signed integer vector. Unsigned integer vectors would cause invalid behavior when the mask vector is widened (unsigned integers would use zero extension, producing incorrect results).
r? ``@workingjubilee``
Update query normalizer docs to not position it as the greatest pioneer in the space of normalization
I don't think its true that we intend to replace all normalization with the query normalizer- its more likely that once the new solver is stable we can replace the query normalizer with normal normalization calls as the new solver caches much more than the old solver
r? ``@compiler-errors``
tests: adapt for LLVM 21 changes
Per discussion in #137799 we don't really need this readonly attribute, so let's just drop it so the test passes on LLVM 21.
Fixes#137799.
Use correct error message casing for `io::const_error`s
Error messages are supposed to start with lowercase letters, but a lot of `io::const_error` messages did not. This fixes them to start with a lowercase letter.
I did consider adding a const check for this to the macro, but some of them start with proper nouns that make sense to uppercase them.
See https://doc.rust-lang.org/1.85.0/std/error/trait.Error.html
rename BackendRepr::Vector → SimdVector
For many Rustaceans, "vector" does not imply "SIMD", so let's be more clear in this type that is used pervasively in the compiler.
r? `@workingjubilee`
Rollup of 8 pull requests
Successful merges:
- #136503 (Tweak output of const panic diagnostic)
- #137390 (tests: fix up new test for nocapture -> capture(none) change)
- #137617 (Introduce `feature(generic_const_parameter_types)`)
- #137719 (Add missing case explanation for doc inlined re-export of doc hidden item)
- #137763 (Use `mk_ty_from_kind` a bit less, clean up lifetime handling in borrowck)
- #137769 (Do not yeet `unsafe<>` from type when formatting unsafe binder)
- #137776 (Some `rustc_transmute` cleanups)
- #137800 (Remove `ParamEnv::without_caller_bounds`)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove `ParamEnv::without_caller_bounds`
This doesn't really do anything that `ParamEnv::empty` doesn't do nowadays as `ParamEnv` *only* stores caller bounds since other information has been moved out into `TypingMode`
r? ```@compiler-errors``` ```@lcnr```
Do not yeet `unsafe<>` from type when formatting unsafe binder
Unsafe binders are types like `unsafe<'a, 'b> Ty<'a, 'b>`. However, users can also specify unsafe binder types with no bound vars, like `unsafe<> Ty`.
When I added nightly formatting for unsafe binders, I didn't consider this, so on nightly we are stripping the `unsafe<>` part, which gives us back `Ty` which is a different type!
This PR fixes that.
r? ``@ytmimi``
Use `mk_ty_from_kind` a bit less, clean up lifetime handling in borrowck
r? ``@BoxyUwU``
Pulled out of my attempt to turn that `*const dyn Tr + '_` casting into a lint (which failed lmao)
Add missing case explanation for doc inlined re-export of doc hidden item
This case was not covered in the rustdoc book as uncovered in #137342.
r? ``@notriddle``
Introduce `feature(generic_const_parameter_types)`
Allows to define const generic parameters whose type depends on other generic parameters, e.g. `Foo<const N: usize, const ARR: [u8; N]>;`
Wasn't going to implement for this for a while until we could implement it with `bad_inference.rs` resolved but apparently the project simd folks would like to be able to use this for some intrinsics and the inference issue isn't really a huge problem there aiui. (cc ``@workingjubilee`` )
tests: fix up new test for nocapture -> capture(none) change
Same change as #136287, but for a newly introduced test.
``@rustbot`` label llvm-main
r? ``@nikic``
Tweak output of const panic diagnostic
### Shorten span of panic failures in const context
Previously, we included a redundant prefix on the panic message and a postfix of the location of the panic. The prefix didn't carry any additional information beyond "something failed", and the location of the panic is redundant with the diagnostic's span, which gets printed out even if its code is not shown.
```
error[E0080]: evaluation of constant value failed
--> $DIR/assert-type-intrinsics.rs:11:9
|
LL | MaybeUninit::<!>::uninit().assume_init();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ panic: aborted execution: attempted to instantiate uninhabited type `!`
```
```
error[E0080]: evaluation of `Fail::<i32>::C` failed
--> $DIR/collect-in-dead-closure.rs:9:19
|
LL | const C: () = panic!();
| ^^^^^^^^ explicit panic
|
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
```
error[E0080]: evaluation of constant value failed
--> $DIR/uninhabited.rs:87:9
|
LL | assert!(false);
| ^^^^^^^^^^^^^^ assertion failed: false
|
= note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)
```
### Remove duplicated span from const eval frame list
When the primary span for a const error is the same as the first frame in the const error report, skip it.
```
error[E0080]: evaluation of constant value failed
--> $DIR/issue-88434-removal-index-should-be-less.rs:3:24
|
LL | const _CONST: &[u8] = &f(&[], |_| {});
| ^^^^^^^^^^^^^^ explicit panic
|
note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>`
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
|
LL | panic!()
| ^^^^^^^^ the failure occurred here
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
instead of
```
error[E0080]: evaluation of constant value failed
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
|
LL | panic!()
| ^^^^^^^^ explicit panic
|
note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>`
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
|
LL | panic!()
| ^^^^^^^^
note: inside `_CONST`
--> $DIR/issue-88434-removal-index-should-be-less.rs:3:24
|
LL | const _CONST: &[u8] = &f(&[], |_| {});
| ^^^^^^^^^^^^^^
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
note: erroneous constant encountered
--> $DIR/issue-88434-removal-index-should-be-less.rs:3:23
|
LL | const _CONST: &[u8] = &f(&[], |_| {});
| ^^^^^^^^^^^^^^^
```
r? ``@oli-obk``
The embedded bitcode should always be prepared for LTO/ThinLTO
Fixes#115344. Fixes#117220.
There are currently two methods for generating bitcode that used for LTO. One method involves using `-C linker-plugin-lto` to emit object files as bitcode, which is the typical setting used by cargo. The other method is through `-C embed-bitcode=yes`.
When using with `-C embed-bitcode=yes -C lto=no`, we run a complete non-LTO LLVM pipeline to obtain bitcode, then the bitcode is used for LTO. We run the Call Graph Profile Pass twice on the same module.
This PR is doing something similar to LLVM's `buildFatLTODefaultPipeline`, obtaining the bitcode for embedding after running `buildThinLTOPreLinkDefaultPipeline`.
r? nikic
Rollup of 9 pull requests
Successful merges:
- #137045 (Defer repeat expr `Copy` checks to end of type checking)
- #137171 (Suggest swapping equality on E0277)
- #137686 (Handle asm const similar to inline const)
- #137689 (Use `Binder<Vec<Ty>>` instead of `Vec<Binder<Ty>>` in both solvers for sized/auto traits/etc.)
- #137718 (Use original command for showing sccache stats)
- #137730 (checked_ilog tests: deal with a bit of float imprecision)
- #137735 (Update E0133 docs for 2024 edition)
- #137742 (unconditionally lower match arm even if it's unneeded for never pattern in match)
- #137771 (Tweak incorrect ABI suggestion and make suggestion verbose)
Failed merges:
- #137723 (Make `rust.description` more general-purpose and pass `CFG_VER_DESCRIPTION`)
r? `@ghost`
`@rustbot` modify labels: rollup
Tweak incorrect ABI suggestion and make suggestion verbose
Provide a better suggestion message, and make the suggestion verbose.
```
error[E0703]: invalid ABI: found `riscv-interrupt`
--> $DIR/riscv-discoverability-guidance.rs:17:8
|
LL | extern "riscv-interrupt" fn isr() {}
| ^^^^^^^^^^^^^^^^^ invalid ABI
|
= note: invoke `rustc --print=calling-conventions` for a full list of supported calling conventions
help: there's a similarly named valid ABI `riscv-interrupt-m`
|
LL | extern "riscv-interrupt-m" fn isr() {}
| ++
```
unconditionally lower match arm even if it's unneeded for never pattern in match
fixes#137708
Lowering arm body is skipped when lowering match arm with never pattern, but we may need the HirId for DefId in the body in later passes. And then we got the ICE `No HirId for DefId`.
Fixes this by lowering the arm body even if it's unneeded for never pattern in match, so that we can generate HirId and use it then.
r? `@compiler-errors`
Update E0133 docs for 2024 edition
The behavior of unsafe_op_in_unsafe_fn was changed in the 2024 edition. This updates this note in the E0133 docs to reflect that change.
Use original command for showing sccache stats
I used the newer advanced command after bumping Linux sccache to 0.9. However, Windows and macOS still use older sccache, so the command didn't work for them (the error was masked on CI though). It sucks that we don't see the Windows/macOS sccache stats, so until we update both of them, just use the older flag with slightly less information.
Use `Binder<Vec<Ty>>` instead of `Vec<Binder<Ty>>` in both solvers for sized/auto traits/etc.
It's more conceptually justified IMO, especially when binders get implications.
r? lcnr
Handle asm const similar to inline const
Previously, asm consts are handled similar to anon consts rather than inline consts. Anon consts are not good at dealing with lifetimes, because `type_of` has lifetimes erased already. Inline consts can deal with lifetimes because they live in an outer typeck context. And since `global_asm!` lacks an outer typeck context, we have implemented asm consts with anon consts while they're in fact more similar to inline consts.
This was changed in #137180, and this means that handling asm consts as inline consts are possible. While as `@compiler-errors` pointed out, `const` currently can't be used with any types with lifetime, this is about to change if #128464 is implemented. This PR is a preparatory PR for that feature.
As an unintentional side effect, fix#117877.
cc `@Amanieu`
r? `@compiler-errors`
Defer repeat expr `Copy` checks to end of type checking
Fixes#110443
Defers repeat expr checks that the element type is `Copy` when the length is > 1 (or generic) to end of typeck so that under `generic_arg_infer` repeat exprs are able to have an inferred count, e.g. `let a: [_; 1] = [String::new(); _];`.
Currently the deferring is gated under `generic_arg_infer` though I intend to separately types FCP deferring the checks even outside of `generic_arg_infer` if we wind up not going with an alternative.
Update cargo
11 commits in 1d1d646c06a84c1aa53967b394b7f1218f85db82..2622e844bc1e2e6123e54e94e4706f7b6195ce3d
2025-02-21 21:38:53 +0000 to 2025-02-28 12:33:57 +0000
- Bump `cc` to 1.2.16 to fix `x86` windows jobs in rust-lang/rust CI (rust-lang/cargo#15245)
- refactor(tree): Abstract the concept of a NodeId (rust-lang/cargo#15237)
- feat: implement RFC 3553 to add SBOM support (rust-lang/cargo#13709)
- refactor(tree): Abstract the concept of an edge (rust-lang/cargo#15233)
- chore: bump openssl to v3 (rust-lang/cargo#15232)
- fix(package): Register workspace member renames in overlay (rust-lang/cargo#15228)
- Implemented `build.build-dir` config option (rust-lang/cargo#15104)
- feat: add completions for `--manifest-path` (rust-lang/cargo#15225)
- chore: semver-check build-rs against beta channel (rust-lang/cargo#15223)
- chore: depend on openssl-sys to correctly pin its version (rust-lang/cargo#15224)
- chore: dont check cargo-util semver until 1.86 is released (rust-lang/cargo#15222)
Error messages are supposed to start with lowercase letters, but a lot
of `io::const_error` messages did not. This fixes them to start with a
lowercase letter.
I did consider adding a const check for this to the macro, but some of
them start with proper nouns that make sense to uppercase them.
See https://doc.rust-lang.org/1.85.0/std/error/trait.Error.html
Previously, we included a redundant prefix on the panic message and a postfix of the location of the panic. The prefix didn't carry any additional information beyond "something failed", and the location of the panic is redundant with the diagnostic's span, which gets printed out even if its code is not shown.
```
error[E0080]: evaluation of constant value failed
--> $DIR/assert-type-intrinsics.rs:11:9
|
LL | MaybeUninit::<!>::uninit().assume_init();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ evaluation panicked: aborted execution: attempted to instantiate uninhabited type `!`
```
```
error[E0080]: evaluation of `Fail::<i32>::C` failed
--> $DIR/collect-in-dead-closure.rs:9:19
|
LL | const C: () = panic!();
| ^^^^^^^^ evaluation panicked: explicit panic
|
= note: this error originates in the macro
`$crate::panic::panic_2015` which comes from the expansion of the macro
`panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
```
error[E0080]: evaluation of constant value failed
--> $DIR/uninhabited.rs:41:9
|
LL | assert!(false);
| ^^^^^^^^^^^^^^ evaluation panicked: assertion failed: false
|
= note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)
```
---
When the primary span for a const error is the same as the first frame in the const error report, skip it.
```
error[E0080]: evaluation of constant value failed
--> $DIR/issue-88434-removal-index-should-be-less.rs:3:24
|
LL | const _CONST: &[u8] = &f(&[], |_| {});
| ^^^^^^^^^^^^^^ evaluation panicked: explicit panic
|
note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>`
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
|
LL | panic!()
| ^^^^^^^^ the failure occurred here
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
instead of
```
error[E0080]: evaluation of constant value failed
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
|
LL | panic!()
| ^^^^^^^^ explicit panic
|
note: inside `f::<{closure@$DIR/issue-88434-removal-index-should-be-less.rs:3:31: 3:34}>`
--> $DIR/issue-88434-removal-index-should-be-less.rs:10:5
|
LL | panic!()
| ^^^^^^^^
note: inside `_CONST`
--> $DIR/issue-88434-removal-index-should-be-less.rs:3:24
|
LL | const _CONST: &[u8] = &f(&[], |_| {});
| ^^^^^^^^^^^^^^
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
---
Revert order of constant evaluation errors
Point at the code the user wrote first and std functions last.
```
error[E0080]: evaluation of constant value failed
--> $DIR/const-errs-dont-conflict-103369.rs:5:25
|
LL | impl ConstGenericTrait<{my_fn(1)}> for () {}
| ^^^^^^^^ evaluation panicked: Some error occurred
|
note: called from `my_fn`
--> $DIR/const-errs-dont-conflict-103369.rs:10:5
|
LL | panic!("Some error occurred");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
instead of
```
error[E0080]: evaluation of constant value failed
--> $DIR/const-errs-dont-conflict-103369.rs:10:5
|
LL | panic!("Some error occurred");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Some error occurred
|
note: called from `<() as ConstGenericTrait<{my_fn(1)}>>::{constant#0}`
--> $DIR/const-errs-dont-conflict-103369.rs:5:25
|
LL | impl ConstGenericTrait<{my_fn(1)}> for () {}
| ^^^^^^^^
= note: this error originates in the macro `$crate::panic::panic_2015` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Rollup of 9 pull requests
Successful merges:
- #136424 (fix: overflowing bin hex)
- #136824 (solver cycles are coinductive once they have one coinductive step)
- #137220 (Support `rust.channel = "auto-detect"`)
- #137712 (Clean up TypeckResults::extract_binding_mode)
- #137713 (Fix enzyme build errors)
- #137748 (Fix method name in `TyCtxt::hir_crate()` documentation)
- #137778 (update enzyme to handle range metadata)
- #137780 (Fix typo in query expansion documentation)
- #137788 (Bump `rustc_{codegen_ssa,llvm}` `cc` to 1.2.16 to fix `x86` Windows jobs on newest Windows SDK)
r? `@ghost`
`@rustbot` modify labels: rollup
linker: Fix escaping style for response files on Windows
If we use a С/С++ compiler as linker, then Posix-style escaping should be used.
Also temporarily fixup rustbuild to not fail at least in common scenarios, until the bootstrap compiler is updated.
Fixes https://github.com/rust-lang/rust/issues/137498
Fix Windows `Command` search path bug
Currently `Command::new` on Windows works differently depending on whether any environment variable is set. For example,
```rust
// Searches for "myapp" in the application and system paths first (aka Windows native behaviour).
Command::new("myapp").spawn();
// Search for "myapp" in `PATH` first
Command::new("myapp").env("a", "b").spawn();
```
This is a bug because the search path should only change if `PATH` is changed for the child (i.e. `.env("PATH", "...")`).
This was discussed in a libs-api meeting where the exact semantics of `Command::new` was not decided but there seemed to be broad agreement that this particular thing is just a bug that can be fixed.
r? libs-api
tests: use minicore more
minicore makes it much easier to add new language items to all of the existing `no_core` tests.
Most of the remaining tests that *could* use minicore either fail because..
1. LLVM IR output changes and doesn't pass the test as written. I didn't look into these further.
2. The test has revisions w/ different compilation flags, expecting some to fail, and when using minicore, minicore is compiled with those flags and fails in the expected way because of the flags rather than the test, and that's considered a failure.
But these tests can be changed and make adding new language items a lot easier.
r? ```@jieyouxu```
import `simd_` intrinsics
In most cases, we can import the simd intrinsics rather than redeclare them. Apparently, most of these tests were written before `std::intrinsics::simd` existed.
There are a couple of exceptions where we can't yet import:
- the intrinsics are not declared as `const fn` in the standard library, causing issues in the `const-eval` tests
- the `simd_shuffle_generic` function is not exposed from `std::intrinsics`
- the `simd_fpow` and `simd_fpowi` functions are not exposed from `std::intrinsics` (removed in https://github.com/rust-lang/rust/pull/137595)
- some tests use `no_core`, and therefore cannot use `std::intrinsics`
r? ```@RalfJung```
cc ```@workingjubilee``` do you have context on why some intrinsics are not exposed?
Fix (more) test directives that were accidentally ignored
Continuation of #137099 , caught by #137103 (and needed to unblock that one).
These test directives were accidentally using the old (`// ```@`)``` syntax
Update some comparison codegen tests now that they pass in LLVM20
Fixes#106107
Needed one tweak to the default `PartialOrd::le` to get the test to pass. Everything but the derived 2-field `le` test passes even without the change to the defaults in the trait.
