Fix run-make tests on musl hosts
On musl hosts, we already set `-Ctarget-feature=-crt-static` and `IS_MUSL_HOST=1` in compiletest. However, in order for the run-make tests to compile fine on musl hosts, we need to propagate this flag in our rustc invocations to ensure we can generate cdylibs.
Option::as_slice: fix comment
The implementation got changed in https://github.com/rust-lang/rust/pull/117525 without updating the comment. Now the comment makes no sense any more since there is no intrinsic that returns a pointer in this function any more.
(It is also very strange to say "in the new version" in a comment -- what is that supposed to tell someone reading the code 2 years later? That wording was introduced even earlier, in https://github.com/rust-lang/rust/pull/109179.)
Cc `@GKFX` `@petrochenkov` `@llogiq` `@scottmcm`
Debug impls for DropElaborators
It's a little weird that these just have a completely empty Debug impl. Now they're `ElaborateDropsCtxt { .. }` and `DropShimElaborator { .. }`.
opt-dist: change build_dir field to be an actual build dir
make it configurable so users can set build.build-dir option in bootstrap.toml
r? Kobzol
try-job: dist-x86_64-msvc
try-job: dist-x86_64-linux
tests: Skip supported-crate-types test on musl hosts
This test depends on the target-specific default of crt-static for musl targets. However, running the testsuite on a musl host requires setting `crt-static` to `false`, as it wouldn't otherwise be possible to build rustc. This in turn will enable `-Ctarget-feature=-crt-static` for all tests, mismatching the expected `+crt-static` for the musl target tested in this testcase.
Since this test specifically tests the default value of `crt-static` for the musl target, ignoring it entirely makes more sense than manually setting `-Ctarget-feature=+crt-static` here, but both would be valid approaches.
Ban projecting into SIMD types [MCP838]
Closes https://github.com/rust-lang/compiler-team/issues/838
The actual compiler change here is tiny; there's just a bazillion tests to update.
~~Since I'm sure I've missed some, for now~~
~~r ghost~~
try-job: test-various
try-job: x86_64-gnu-nopt
On musl hosts, we already set -Ctarget-feature=-crt-static and
IS_MUSL_HOST=1 in compiletest. However, in order for the run-make tests
to compile fine on musl hosts, we need to propagate this flag in our
rustc invocations to ensure we can generate cdylibs.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
Give a message with a span on MIR validation error
It was handy to get a source+line link for rust-lang/rust#143833, even if it's just to the function and not necessarily to the statement.
r? mir
Fix `-Ctarget-feature`s getting ignored after `crt-static`
The current behaviour introduced by commit a50a3b8e31 would discard any target features specified after `crt-static` (the only member of `RUSTC_SPECIFIC_FEATURES`). This is because it returned instead of continuing processing the next feature.
I wasn't entirely sure how the regression test should look like, but this one should do. If anyone has some suggestions, I'm happy to learn, it's my first test :)
I've confirmed that the test fails without the fix on `powerpc64le-unknown-linux-musl` and `x86_64-unknown-linux-gnu`.
cc ``@RalfJung``
Add new `ignore-backends` and `needs-backends` tests annotations
Part of https://github.com/rust-lang/compiler-team/issues/891.
Next step will be to add these annotations in the files where either the output is different based on the codegen (like `asm` tests) or that are known to fail in the GCC backend.
cc `@oli-obk` `@antoyo`
r? `@Kobzol`
bootstrap: Ignore `rust.debuginfo-level-tests` for codegen tests
As dicussed in https://github.com/rust-lang/rust/issues/61117#issuecomment-495587364, codegen tests typically depend on the raw LLVM IR output and are sensitive to debuginfo level. So do not apply `rust.debuginfo-level-tests` for codegen tests.
Before this commit:
$ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
test result: FAILED. 654 passed; 136 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.22s
After this commit:
$ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
NOTE: ignoring `rust.debuginfo-level-tests=2` for codegen tests
test result: ok. 790 passed; 0 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.21s
### Run this in CI?
Maybe it will make sense to add this to CI later but I think it is too early to do now before more non-codegen tests work with `rust.debuginfo-level-tests=2`.
bootstrap: Don't trigger an unnecessary LLVM build from check builds
Coming back to r-l/r development after a few weeks away, I found a major regression in my dev workflows: running `x check compiler` (either manually or via rust-analyzer) would have the side-effect of building LLVM, even though that shouldn't be necessary.
For my main build directory this would be a minor annoyance, but for my separate rust-analyzer build directory it's a huge problem because it causes a completely separate build of LLVM, which takes a long time and should be completely unnecessary.
---
After some investigation, I tracked down the problem to the `can_skip_build` check in this code:
3014e79f9c/src/bootstrap/src/core/build_steps/compile.rs (L1382-L1396)
Historically, this would skip the LLVM build for stage 0 check builds. But after the recent stage 0 std redesign and some associated check stage renumbering (e.g. rust-lang/rust#143048), the condition `builder.top_stage == build_stage` is now false, because `top_stage` is 1 (due to the renumbering) but `build_stage` is 0 (because a “stage 1” non-library check build still uses the stage 0 compiler).
---
Because this is a critical contributor roadblock for me, I have tried to fix this in a relatively narrow way. It's possible that all of this surrounding logic could be greatly simplified (especially in light of the stage redesign changes), but I didn't want this fix to be held back by scope creep.
---
(Zulip thread: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Bootstrap.20incorrectly.20building.20LLVM.20for.20check.20builds/near/528991035)
Allow `Rvalue::Repeat` to return true in `rvalue_creates_operand` too
The conversation in https://github.com/rust-lang/rust/pull/143502#discussion_r2189410911 made be realize how easy this is to handle, since the only possibilty is ZSTs -- everything else ends up with the destination being `LocalKind::Memory` and thus doesn't call `codegen_rvalue_operand` at all.
This gets us perilously close to a world where `rvalue_creates_operand` only ever returns true. (See rust-lang/rust#143860 for more.)
address clippy formatting nits
- int_log10.rs: change top level doc comments to outer
- collect.rs: remove empty line after doc comment
- clippy fix: markdown indentation for indented items after line break: a markdown list item continued over multiples lines, but those following lines which are part of the same item are not indented
- clippy fix: bound in one place: when there is a bound in angle brackets and another bound on the same variable in a where clause
Fixes for LLVM 21
This fixes compatibility issues with LLVM 21 without performing the actual upgrade. Split out from https://github.com/rust-lang/rust/pull/143684.
This fixes three issues:
* Updates the AMDGPU data layout for address space 8.
* Makes emit-arity-indicator.rs a no_core test, so it doesn't fail on non-x86 hosts.
* Explicitly sets the exception model for wasm, as this is no longer implied by `-wasm-enable-eh`.
Remove deprecated `MaybeUninit` slice methods
These were left in to make migration a bit easier, although they should be removed now since they were never stable.
[rustdoc] Make aliases search support partial matching
Fixesrust-lang/rust#140782.
To make this work, I moved aliases into the `searchIndex` like any other item. It links to the "original" item with a new `original` field. No so great part is that we need to have some fields like `bitIndex` to be set on the alias to make the description load to work but I consider it minor enough to be ok.
This PR voluntarily doesn't handle de-prioritization of aliases as ```@lolbinarycat``` wished to work on this so I'll leave them this part. 😉
cc ```@lolbinarycat```
