These are quite long, usually, and in most cases not interesting. On smaller
terminals they can take up more than a full page of output, hiding the error
diagnostics emitted.
Fix caching issue when building tools.
This fixes a problem with tool builds not being cached properly.
#73297 changed it so that Clippy will participate in the "deny warnings" setting. Unfortunately this causes a problem because Clippy shares the build directory with other tools which do not participate in "deny warnings". Because Cargo does not independently cache artifacts based on different RUSTFLAGS settings, it causes all the shared dependencies to get rebuilt if Clippy ever gets built.
The solution here is to stop using RUSTFLAGS, and just sneak the settings in through the rustc wrapper. Cargo won't know about the different settings, so it will not bust the cache. This should be safe since lint settings on dependencies are ignored. This is how things used to work in the past before #64316.
Alternate solutions:
* Treat Clippy as a "submodule" and don't enforce warnings on it. This was the behavior before #73297. The consequence is that if a warning sneaks into clippy, that the clippy maintainers will need to fix it when they sync clippy back to the clippy repo.
* Just deny warnings on all tools (removing the in-tree/submodule distinction). This is tempting, but with some issues (cc #52336):
* Adding or changing warnings in rustc can be difficult to land because tools have to be updated if they trip the warning. In practice, this isn't too bad. Cargo (and rustfmt) already runs with `deny(warnings)`, so this has been the de-facto standard already (although they do not use the extra lints like `unused_lifetimes`).
* Teach Cargo to add flags to the workspace members, but not dependencies.
* Teach Cargo to add flags without fingerprinting them?
* Teach Cargo to independently cache different RUSTFLAGS artifacts (this was [reverted](https://github.com/rust-lang/cargo/pull/7417) due to complications). This would also unnecessarily rebuild dependencies, but would avoid cache thrashing.
* Teach Cargo about lint settings.
Closes#74016
This commit moves the compiler-builtins-specific build logic from
`src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s
`[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can
ensure that Cargo knows about debug assertions settings, and it can also
be configured to specifically disable debug assertions unconditionally
for compiler-builtins. This should improve rebuild logic when
debug-assertions settings change and also improve build-std integration
where Cargo externally now has an avenue to learn how to build
compiler-builtins as well.
Add an option to use LLD to link the compiler on Windows platforms
Based on https://github.com/rust-lang/rust/pull/68609.
Using LLD is good way to improve compile times on Windows since `link.exe` is quite slow. The time for `x.py build --stage 1 src/libtest` goes from 0:12:00 to 0:08:29. Compile time for `rustc_driver` goes from 226.34s to 18.5s. `rustc_macros` goes from 28.69s to 7.7s. The size of `rustc_driver` is also reduced from 83.3 MB to 78.7 MB.
r? @Mark-Simulacrum
use the code generation parameter -Clinker (same parameter as rustc)
to control what linker to use for building the rustdoc test executables.
closes: #63816
When deny-warnings is not specified or set to true, the behaviour is the same as before.
When deny-warnings is set to false, warnings are now allowed
Fixes#63911
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
Rename overflowing_{add,sub,mul} intrinsics to wrapping_{add,sub,mul}.
These confused @Gankra, and then, also me, especially since `overflowing_*` *methods* also exist, but they map to `*_with_overflow` intrinsics!
r? @oli-obk / @nikomatsakis cc @Mark-Simulacrum (on the rustbuild workaround)
Remap paths for proc-macro crates.
The remap-debuginfo config option remaps paths in most crates, but it does not apply to proc-macros, so they are still non-reproducible. This patch fixes that.
I'm not completely sure if this is the best way to do this, but to get reproducible builds we need librustc_macros to be built with --remap-path-prefix. I was previously modifying Cargo to pass that argument to all child crates, so this seems simpler and more correct.
I did not add a test since there do not seem to be any existing tests for RUSTC_DEBUGINFO_MAP.
r? @alexcrichton
The remap-debuginfo config option remaps paths in most crates, but it
does not apply to proc-macros, so they are still non-reproducible.
This patch fixes that.
