Rollup of 12 pull requests
Successful merges:
- #123423 (Distribute LLVM bitcode linker as a preview component)
- #123548 (libtest: also measure time in Miri)
- #123666 (Fix some typos in doc)
- #123864 (Remove a HACK by instead inferring opaque types during expected/formal type checking)
- #123896 (Migrate some diagnostics in `rustc_resolve` to session diagnostic)
- #123919 (builtin-derive: tag → discriminant)
- #123922 (Remove magic constants when using `base_n`.)
- #123931 (Don't leak unnameable types in `-> _` recover)
- #123933 (move the LargeAssignments lint logic into its own file)
- #123934 (`rustc_data_structures::graph` mini refactor)
- #123941 (Fix UB in LLVM FFI when passing zero or >1 bundle)
- #123957 (disable create_dir_all_bare test on all(miri, windows))
r? `@ghost`
`@rustbot` modify labels: rollup
libtest: also measure time in Miri
A long time ago we disabled timekeeping of the default test harness in Miri, as otherwise it would fail to run without `-Zmiri-disable-isolation`. However, since then Miri gained a "fake clock" that lets it present some deterministic notion of time when isolation is enabled.
So we could now let libtest do timekeeping again when running in Miri. That's nice as it can help detect tests that run too long. However it can also be confusing as the results with isolation can be quite different than the real time.
``@rust-lang/miri`` what do you think?
Miri on Windows: run .CRT$XLB linker section on thread-end
Hopefully fixes https://github.com/rust-lang/rust/issues/123583
First commit is originally by `@bjorn3`
r? `@oli-obk`
Cc `@ChrisDenton`
compiletest ice tracking
see https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/where.20to.20mass-add.20known.20ices.20.2F.20merging.20glacier.20into.20rust/near/429082963
This will allow us to sunset most of https://github.com/rust-lang/glacier
The rustc ices will be tracked directly inside the rust testsuite
There are a couple of .sh tests remaining that I have not ported over yet.
This adds `tests/crashes`, a file inside this directory MUST ice, otherwise it is considered test-fail.
This will be used to track ICEs from glacier and the bugtracker.
When someones pr accidentally fixes one of these ICEs, they can move the test from `crashes` into `ui` for example.
I also added a new tidy lint that warns when a test inside `tests/crashes` does not have a `//@ known-bug: ` line
the env var `COMPILETEST_VERBOSE_CRASHES` can be set to get exit code, stderr and stdout of a crash-test to aid debugging/adding tests.
ci: test cargo on `aarch64-gnu`
Since `aarch64-unknown-linux-gnu` is a tier-1 target, we should also test cargo on it, especially since cargo's own CI doesn't cover this yet. This might have helped us discover #123733 sooner, which is not a cargo problem but was uncovered by a new cargo test (which we'll have to skip for now). Everything else passes in my local run, so at least we'll have a guard against future regressions.
skip Codegen{GCC,Cranelift} when using CI rustc
CI rustc uses the default codegen backend, therefore we can't run `CodegenGCC` and `CodegenCranelift` tests when using it.
cc `@bjorn3` (to make sure I am not doing anything wrong)
Fixes#123331
previously we would explicitly look for exit code 101 and call it a crash,
however in case of stack overflows for example, exit code could differ due to the
process being killed by a signal which is not easy to detect on none-unix.
So now we reject everything that exits with 0 (no error) or 1 (compiler failed to compile code)
and "accept" everyhing else as an internal compiler error.
compiletest: Update rustfix to 0.8.1
This updates the version of rustfix used in compiletest to be closer to what cargo is using. This is to help ensure `cargo fix` and compiletest are aligned. There are some unpublished changes to `rustfix`, which will update in a future PR when those are published.
Will plan to update ui_test in the near future to avoid the duplicate.
reduce tidy overheads in run-make checks
This change makes tidy to handle run-make checks with a single iteration, avoiding the need for multiple iterations and copying.
run-make-support: tidy up support library
- Make `handle_failed_output` take `&Command` instead of having the caller keep doing `format!("{:#?}", s)`.
- Introduce a helper macro for implementing common command wrappers, such as `arg`, `args`, `run`, `run_fail`.
- Use the helper macro on existing command wrappers and remove manual copy-pasta'd implementations.
bootstrap: move all of rustc's flags to `rustc_cargo`
This ensures that `RUSTFLAGS` will be consistent between all modes of
building the compiler, so they won't trigger a rebuild by cargo. This
kind of fix was started in #119414 just for LTO flags, but it's
applicable to all kinds of flags that might be configured.
Add a helper macro for adding common methods to command wrappers. Common
methods include helpers that delegate to `Command` and running methods.
- `arg` and `args` (delegates to `Command`)
- `env`, `env_remove` and `env_clear` (delegates to `Command`)
- `output`, `run` and `run_fail`
This helps to avoid needing to copy-pasta / reimplement these common
methods on a new command wrapper, which hopefully reduces the friction
for run-make test writers wanting to introduce new command wrappers.
do not allow using local llvm while using rustc from ci
From: https://github.com/rust-lang/rust/issues/123586#issuecomment-2043296578
> Even if `llvm.download-ci-llvm` is set to true, `stage > 0` rustc will always use the prebuilt LLVM library which comes with ci-rustc. So I tried to use locally-built LLVM libraries in the ci-rustc by replacing the existing LLVM libraries with the locally built ones, and it appears that this is indeed a limitation of using `rust.download-rustc=true` as it fails with the following error:
>
> ```
> $ ./build/host/ci-rustc/bin/rustc --version
> ./build/host/ci-rustc/bin/rustc: symbol lookup error: /home/nimda/devspace/.other/rustc-builds/build/x86_64-unknown-linux-gnu/ci-rustc/bin/../lib/librustc_driver-a03ea465d8e03db1.so: undefined symbol: LLVMInitializeARMTargetInfo, version LLVM_18.1
> ```
>
> So, if `rust.download-rustc` is set to true and `llvm.download-ci-llvm` is false, I believe bootstrap should terminate the process (as it always uses prebuilt LLVM libraries from ci-rustc, there is no point to build LLVM locally) while parsing the configuration.
Resolves#123586
r? Mark-Simulacrum
Enable building tier2 target riscv32im-unknown-none-elf
riscv32im-unknown-none-elf was promoted to tier2 in
https://github.com/rust-lang/rust/pull/117874
but it has not yet been added to the list of build targets.
By adding riscv32im-unknown-none-elf to the list of build targets, this PR enables end-users to install this target via rustup.
Linker flavors next steps: linker features
This is my understanding of the first step towards `@petrochenkov's` vision for the future of linker flavors, described in https://github.com/rust-lang/rust/pull/119906#issuecomment-1895693162 and the discussion that followed.
To summarize: having `Cc` and `Lld` embedded in linker flavors creates tension about naming, and a combinatorial explosion of flavors for each new linker feature we'd want to use. Linker features are an extension mechanism that is complementary to principal flavors, with benefits described in #119906.
The most immediate use of this flag would be to turn self-contained linking on and off via features instead of flavors. For example, `-Clinker-features=+/-lld` would toggle using lld instead of selecting a precise flavor, and would be "generic" and work cross-platform (whereas linker flavors are currently more tied to targets). Under this scheme, MCP510 is expected to be `-Clink-self-contained=+linker -Zlinker-features=+lld -Zunstable-options` (though for the time being, the original flags using lld-cc flavors still work).
I purposefully didn't add or document CLI support for `+/-cc`, as it would be a noop right now. I only expect that we'd initially want to stabilize `+/-lld` to begin with.
r? `@petrochenkov`
You had requested that minimal churn would be done to the 230 target specs and this does none yet: the linker features are inferred from the flavor since they're currently isomorphic. We of course expect this to change sooner rather than later.
In the future, we can allow targets to define linker features independently from their flavor, and remove the cc and lld components from the flavors to use the features instead, this actually doesn't need to block stabilization, as we discussed.
(Best reviewed per commit)
This change makes tidy to handle run-make checks with a single iteration,
avoiding the need for multiple iterations and copying.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Add `/System/iOSSupport` to the library search path on Mac Catalyst
On macOS, `/System/iOSSupport` contains iOS frameworks like UIKit, which is the whole idea of Mac Catalyst.
To link to these, we need to explicitly tell the linker about the support library stubs provided in the macOS SDK under the same path.
Concretely, when building a binary for Mac Catalyst, Xcode passes the following flags to the linker:
```
-iframework /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/System/iOSSupport/System/Library/Frameworks
-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/System/iOSSupport/usr/lib
```
This is not something that can be disabled (it's enabled as soon as you enable `SUPPORTS_MACCATALYST`), so I think it's pretty safe to say that we don't need an option to turn these off.
I've chosen to slightly deviate from what Xcode does and use `-F` instead of `-iframework`, since we don't need to change the header search path, and this way the flags nicely match on all the linkers. From what I could tell by reading Clang sources, there shouldn't be a difference when just running the linker.
CC `@BlackHoleFox,` `@shepmaster` (I accidentally let rustbot choose the reviewer).
Set the host library path in run-make v2
When the build is configured with `[rust] rpath = false`, we need to set
`LD_LIBRARY_PATH` (or equivalent) to what would have been the `RPATH`,
so the compiler can find its own libraries. The old `tools.mk` code has
this environment prefixed in the `$(BARE_RUSTC)` variable, so we just
need to wire up something similar for run-make v2.
This is now set while building each `rmake.rs` itself, as well as in the
`rust-make-support` helpers for `rustc` and `rustdoc` commands. This is
also available in a `set_host_rpath` function for manual commands, like
in the `compiler-builtins` test.
Michael Goulet