move uefi test to run-make
Turn the `uefi` test into a more standard `run-make` test, and execute it using the `test-various` CI job like before.
This is just a straightforward translation of the python code, but using `run-make` to supply the target (hence the 3 separate calls in the docker file).
r? ```@jieyouxu```
cc ```@nicholasbishop```
try-job: test-various
No longer need `alloca`s for consuming `Result<!, i32>` and similar
In optimized builds GVN gets rid of these already, but in `opt-level=0` we actually make `alloca`s for this, which particularly impacts `?`-style things that use actually-only-one-variant types like this.
While doing so, rewrite `LocalAnalyzer::process_place` to be non-recursive, solving a 6+ year old FIXME.
r? codegen
`rustdoc` was filling a `target_modifiers` variable, but it was not
using the result.
In turn, that means that trying to use a dependency that set a target
modifier fails.
For instance, running:
```sh
RUSTC_BOOTSTRAP=1 rustc --edition=2024 --target=aarch64-unknown-none-softfloat --sysroot=/dev/null --emit=metadata -Zfixed-x18 --crate-type rlib --crate-name core $(rustc --print sysroot)/lib/rustlib/src/rust/library/core/src/lib.rs
echo '#![allow(internal_features)]
' | RUSTC_BOOTSTRAP=1 rustdoc --edition=2021 --target=aarch64-unknown-none-softfloat --sysroot=/dev/null -Zfixed-x18 --extern core=libcore.rmeta -
```
will fail with:
```text
error: mixing `-Zfixed-x18` will cause an ABI mismatch in crate `rust_out`
|
= help: the `-Zfixed-x18` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely
= note: unset `-Zfixed-x18` in this crate is incompatible with `-Zfixed-x18=` in dependency `core`
= help: set `-Zfixed-x18=` in this crate or unset `-Zfixed-x18` in `core`
= help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=fixed-x18` to silence this error
```
Thus save the targets modifiers in `Options` to then pass it to the
session options, so that eventually the diff can be performed as expected
in `report_incompatible_target_modifiers()`.
Fixes: https://github.com/rust-lang/rust/issues/144521
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
canonicalize build root in `tests/run-make/linker-warning`
r? jieyouxu
This is similar to rust-lang/rust#139823 -- the test fails for me because my build dir is a symlink.
tests: aarch64-outline-atomics: Remove hardcoded target
Since this test is limited to aarch64 and linux hosts, the `--target` flag is entirely unnecessary and only breaks this on musl hosts. Let the compiler use the default target instead.
Stop compilation early if macro expansion failed
Fixesrust-lang/rust#116180.
So there isn't really a type that is central for macro expansion and some errors are actually emitted (because the resolution happens after the expansion I suppose) after the expansion pass (like "not found macro"). Sometimes, errors are only emitted on the second "try" (to improve error output). So I couldn't reach a similar solution than what was done in https://github.com/rust-lang/rust/pull/133937 and suggested by ````@estebank```` in https://github.com/rust-lang/rust/issues/116180#issuecomment-3109468922. But maybe I missed something?
So in the end, I realized that there is method called every time (except one, described below) a macro error is actually emitted: `ExtCtxt::trace_macros_diag`. Considering I updated what it did, I renamed it into `macro_error_and_trace_macros_diag` to better reflect it.
There is only one call of `trace_macros_diag` which isn't reporting an error but just used for `macro_trace` feature, so I kept it as is.
r? ````@oli-obk````
test using multiple c-variadic ABIs in the same program
tracking issue: https://github.com/rust-lang/rust/issues/100189
Check that multiple c-variadic calling conventions can be used in the same program.
Clang and gcc reject defining functions with a non-default calling convention and a variable
argument list, so C programs that use multiple c-variadic calling conventions are unlikely
to come up. Here we validate that our codegen backends do in fact generate correct code.
(CI will not run this test because it runs on aarch64, I would like to at least test that this runs on windows)
try-job: `x86_64-gnu`
try-job: `x86_64-msvc-*`
try-job: `x86_64-apple-2`
Let `codegen_transmute_operand` just handle everything
When combined with rust-lang/rust#143720, this means `rvalue_creates_operand` can just return `true` for *every* `Rvalue`. (A future PR could consider removing it, though just letting it optimize out is fine for now.)
It's nicer anyway, IMHO, because it avoids needing the layout checks to be consistent in the two places, and thus is an overall reduction in code. Plus it's a more helpful building block when used in other places this way.
(TBH, it probably would have been better to have it this way the whole time, but I clearly didn't understand `rvalue_creates_operand` when I originally wrote rust-lang/rust#109843.)
Allow pretty printing paths with `-Zself-profile-events=args`
`-Zself-profile-events=args` is pretty heavy and can pretty print a lot of stuff. Rather than hunting down specific cases where this happens, I'd just allow calling `trimmed_def_paths` in this mode.
Fixes: https://github.com/rust-lang/rust/issues/144457
r? `@RalfJung`
Suggest unwrapping when private method name is available in inner type
Given
```rust
fn main() {
let maybe_vec = Some(vec![1,2,3]);
assert_eq!(maybe_vec.len(), 3);
}
```
suggest unwraping `maybe_vec` to call `.len()` on the `Vec<_>`.
```
error[E0624]: method `len` is private
--> $DIR/enum-method-probe.rs:61:9
|
LL | res.len();
| ^^^ private method
--> $SRC_DIR/core/src/option.rs:LL:COL
|
= note: private method defined here
|
note: the method `len` exists on the type `Vec<{integer}>`
--> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL
help: consider using `Option::expect` to unwrap the `Vec<{integer}>` value, panicking if the value is an `Option::None`
|
LL | res.expect("REASON").len();
| +++++++++++++++++
```
When a method isn't available, we emit E0599, but when it is private we emit E0624. We now just invoke the same suggestion logic from the later that we already did in the former.
Fixrust-lang/rust#143795.
Disable has_reliable_f128_math on musl targets
musl does not implement the symbols required by rustc for f128 maths. Disable the associated cfg for all musl targets and adjust the tests accordingly.
Closesrust-lang/rust#144423
tests: debuginfo: Work around or disable broken tests on powerpc
f16 support for PowerPC has issues in LLVM, therefore we need a small workaround to prevent LLVM from emitting symbols that don't exist for PowerPC yet.
It also appears that rust-lang/rust#128973 applies to PowerPC targets as well, though I've only tested 64-bit Linux targets.
Fix unused_parens false positive
Resolvesrust-lang/rust#143653.
The "no bounds exception" was indiscriminately set to `OneBound` for referents and pointees. However, if the reference or pointer type itself appears in no-bounds position, any constraints it has must be propagated.
```rust
// unused parens: not in no-bounds position
fn foo(_: Box<(dyn Send)>) {}
// unused parens: in no-bounds position, but one-bound exception applies
fn bar(_: Box<dyn Fn(&u32) -> &(dyn Send)>) {}
// *NOT* unused parens: in no-bounds position, but no exceptions to be made
fn baz(_: Box<dyn Fn(&u32) -> &(dyn Send) + Send>) {}
```
Enable const-vector.rs test on RISC-V (riscv64)
This PR replaces [#144283](https://github.com/rust-lang/rust/pull/144283) to resolve merge conflicts.
This PR adds support for running the `tests/codegen/const-vector.rs` test on the RISC-V (riscv64) architecture.
Previously, this test would fail on RISC-V targets due to architecture-specific code generation issues. This patch modifies the test to ensure compatibility while preserving its intent.
The change has been tested locally using `./x test` on a riscv64 target, and the test now passes as expected.
### Notes:
- This change is scoped specifically to improve RISC-V compatibility.
- It does not affect behavior or test results on other architectures.
Enable dwarf-mixed-versions-lto.rs test on RISC-V (riscv64)
This PR replaces [#144284](https://github.com/rust-lang/rust/pull/144284) to resolve merge conflicts.
This PR adds support for running the `tests/assembly/dwarf-mixed-versions-lto.rs` test on the RISC-V (riscv64) architecture.
Previously, this test would fail on RISC-V targets due to architecture-specific code generation issues. This patch modifies the test to ensure compatibility while preserving its intent.
The change has been tested locally using `./x test` on a riscv64 target, and the test now passes as expected.
### Notes:
- This change is scoped specifically to improve RISC-V compatibility.
- It does not affect behavior or test results on other architectures.
Mention type that could be `Clone` but isn't in more cases
When encountering a moved value of a type that isn't `Clone` because of unmet obligations, but where all the unmet predicates reference crate-local types, mention them and suggest cloning, as we do in other cases already:
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:14:25
|
13 | fn do_stuff(foo: Option<Foo>) {
| --- captured outer variable
14 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
15 | if foo.map_or(false, |f| f.foo()) {
| ---
| |
| variable moved due to use in coroutine
| move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
|
note: if `Foo` implemented `Clone`, you could clone the value
--> f111.rs:4:1
|
4 | struct Foo;
| ^^^^^^^^^^ consider implementing `Clone` for this type
...
15 | if foo.map_or(false, |f| f.foo()) {
| --- you could clone this value
```
CC rust-lang/rust#68119.
Rehome 35 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
rust-lang/rust#143902 divided into smaller, easier to review chunks.
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
The URL addition at the end, as well as moving around the auxiliary files and editing the `stderr` files with the new filename, were done using a Python script.
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
musl does not implement the symbols required by std for f128 maths.
Disable the associated cfg for all musl targets and adjust the tests
accordingly.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
When encountering a moved value of a type that isn't `Clone` because of unmet obligations, but where all the unmet predicates reference crate-local types, mention them and suggest cloning, as we do in other cases already:
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:14:25
|
13 | fn do_stuff(foo: Option<Foo>) {
| --- captured outer variable
14 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
15 | if foo.map_or(false, |f| f.foo()) {
| ---
| |
| variable moved due to use in coroutine
| move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
|
note: if `Foo` implemented `Clone`, you could clone the value
--> f111.rs:4:1
|
4 | struct Foo;
| ^^^^^^^^^^ consider implementing `Clone` for this type
...
15 | if foo.map_or(false, |f| f.foo()) {
| --- you could clone this value
```
