Fix path to run clippy on rustdoc
Took me a while to find out that the path clippy expected was `src/tools/rustdoc` and not `src/librustdoc`. I think it makes more sense this way as most commands rely on source paths.
r? ```@Kobzol```
More work on `zstd` compression
r? ``@Kobzol`` as we've discussed this.
This is a draft to show the current approach of supporting zstd in compiletest, and making the tests using it unconditional.
Knowing whether llvm/lld was built with `LLVM_ENABLE_ZSTD` is quite hard, so there are two strategies. There are details in the code, and we can discuss this approach. Until we know the config used to build CI artifacts, it seems our options are somewhat limited in any case.
zlib compression seems always enabled, so we only check this in its dedicated test, allowing the test to ignore errors due to zstd not being supported.
The zstd test is made unconditional in what it tests, by relying on `needs-llvm-zstd` to be ignored when `llvm.libzstd` isn't enabled in `config.toml`.
try-job: x86_64-gnu
try-job: x86_64-msvc
try-job: x86_64-gnu-distcheck
handle stage0 `cargo` and `rustc` separately
This change allows setting either `build.cargo` or `build.rustc` without requiring both to be set simultaneously, which was not possible previously.
To try it, set `build.rustc` without setting `build.cargo`, and try to bootstrap on clean build.
Blocker for https://github.com/rust-lang/rust/pull/129152
Build `library/profiler_builtins` from `ci-llvm` if appropriate
Running all of `tests/coverage` requires the LLVM profiler runtime, which requires setting `build.profiler = true`.
Historically, doing that has required checking out the entire `src/llvm-project` submodule. For compiler contributors who otherwise don't need that submodule (thanks to `download-ci-vm`), that's quite inconvenient.
However, thanks to #129116, the downloaded CI LLVM tarball now contains a copy of LLVM's `compiler-rt` directory, which includes all the files needed to build the profiler runtime. So with a little bit of extra logic in bootstrap, we can have `library/profiler_builtins` look for the `compiler-rt` files in `ci-llvm` instead of the `src/llvm-project` submodule.
This change allows setting either `build.cargo` or `build.rustc` without requiring
both to be set simultaneously, which was not possible previously.
To try it, set `build.rustc` without setting `build.cargo`, and try to bootstrap on clean build.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Rollup of 9 pull requests
Successful merges:
- #128511 (Document WebAssembly target feature expectations)
- #129243 (do not build `cargo-miri` by default on stable channel)
- #129263 (Add a missing compatibility note in the 1.80.0 release notes)
- #129276 (Stabilize feature `char_indices_offset`)
- #129350 (adapt integer comparison tests for LLVM 20 IR changes)
- #129408 (Fix handling of macro arguments within the `dropping_copy_types` lint)
- #129426 (rustdoc-search: use tighter json for names and parents)
- #129437 (Fix typo in a help diagnostic)
- #129457 (kobzol vacation)
r? `@ghost`
`@rustbot` modify labels: rollup
Ship MinGW-w64 runtime DLLs along with `rust-lld.exe` for `-pc-windows-gnu` targets
`rust-lld.exe` built for `x86_64-pc-windows-gnu` depends on `libgcc_s_seh-1.dll` and `libwinpthread-1.dll` from MinGW-w64. Until now, they were not shipped alongside `rust-lld.exe`, and you could not run `rust-lld.exe` on most systems.
This problem didn't surface until now because:
* Most targets don't use `rust-lld` by default.
* Some people had these DLLs in their `PATH` from some other MinGW binary.
* `rustup` used to add `bin` to the `PATH`, which contains these DLLs for `rustc.exe`. But it no longer does that: ce3c09a0cbFixes#125809
try-job: dist-x86_64-mingw
improve submodule updates
During config parsing, some bootstrap logic (e.g., `download-ci-llvm`) checks certain sources (for `download-ci-llvm`, it's `src/llvm-project`) and acts based on their state. This means that if path is a git submodule, bootstrap needs to update it before checking its state. Otherwise it may make incorrect assumptions by relying on outdated sources. To enable submodule updates during config parsing, we need to move the `update_submodule` function from the `Build` to `Config`, so we can access to it during the parsing process.
Closes#122787
bootstrap: fix clean's remove_dir_all implementation
It turns out bootstrap's `clean.rs`'s hand-rolled `rm_rf` (which probably comes before `std::fs::remove_dir_all` was stable) is very broken on native Windows around both read-only files/directories and especially symbolic links. So instead of rolling our own, just use `std::fs::remove_dir_all`.
This is a blocker for compiletest's own `rm_rf` implementation #129155 which happens to be also buggy, which in turn is a blocker for the rmake.rs test port #128562 that heavily exercises symlinks (I was reviewing #128562 and testing it on native Windows which is how I found out).
I also left a FIXME for `detect_src_and_out` due to a failing assertion on native Windows (opened #129188):
```
---- core::config::tests::detect_src_and_out stdout ----
thread 'core::config::tests::detect_src_and_out' panicked at src\core\config\tests.rs:72:13:
assertion `left == right` failed
left: "E:\\tmp"
right: "C:\\tmp"
```
Fixes#112544 (because now we handle Windows symlinks properly).
try-job: x86_64-msvc
try-job: i686-mingw
try-job: test-various
try-job: armhf-gnu
try-job: aarch64-apple
try-job: aarch64-gnu
Switch to using the v2 resolver in most workspaces
Pinning the resolver to v1 was done in 5abff3753a ("Explicit set workspace.resolver ...") in order to suppress warnings. Since there is no specific reason not to use the new resolver and since it fixes issues, change to `resolver = "2"` everywhere except library.
Include a copy of `compiler-rt` source in the `download-ci-llvm` tarball
This will make it possible to experiment with allowing `download-ci-llvm` builds to build `library/profiler_builtins`, without needing to check out the `src/llvm-project` submodule.
By itself, this PR just adds the files to the tarball, but doesn't actually do anything with them. The idea is that once this is merged, it will then be much easier to proceed with work on the necessary bootstrap changes (using the real downloaded tarball), without having to rig up weird hacks to simulate downloading a modified tarball.
---
Adding these files to the compressed tarballs appears to increase its size by a negligible amount (<1 MB out of 400/800+ MB).
The uncompressed size is about 14 MB (out of 2+ GB for the whole tarball).
(The excluded test files would have been another 35 MB.)
With the new resolver, a few dependencies get brought in twice with
different licenses. For example, all dependencies from `wasm-tools`
gained Apache-2.0 and MIT options, and with the v2 resolver we were
using one version from before and one version from after this change.
This made tidy's license check difficult.
Update some minimum versions to remove duplicate dependencies and smooth
out license checking.
During config parsing, some bootstrap logic (e.g., `download-ci-llvm`) checks certain sources
and acts based on their state. This means that if path is a git submodule, bootstrap needs to
update it before checking its state. Otherwise it may make incorrect assumptions by relying on
outdated sources. To enable submodule updates during config parsing, we need to move the `update_submodule`
function from the `Build` to `Config` instance, so we can access to it during the parsing process.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
... by using `std::fs::remove_dir_all`, which handles a bunch of edge
cases including read-only files and symlinks which are extremely tricky
on Windows.
detect incompatible CI rustc options more precisely
Previously, the logic here was simply checking whether the option was set in `config.toml`. This approach was not manageable in our CI runners as we set so many options in config.toml. In reality, those values are not incompatible since they are usually the same value used to generate the CI rustc. Now, the new logic compares the configuration values with the values used to generate the CI rustc, so we get more precise results and make the process more manageable.
r? Kobzol
Blocker for https://github.com/rust-lang/rust/pull/122709
`rust-lld.exe` built for `x86_64-pc-windows-gnu` depends on `libgcc_s_seh-1.dll` and `libwinpthread-1.dll` from MinGW-w64.
Until now, they were not shipped alongside `rust-lld.exe`, and you could not run `rust-lld.exe` on most systems.
This problem didn't surface until now because:
* Most targets don't use `rust-lld` by default.
* Some people had these DLLs in their `PATH` from some other MinGW binary.
* `rustup` used to add `bin` to the `PATH`, which contains these DLLs for `rustc.exe`. But it no longer does that: ce3c09a0cbFixes#125809
