Otherwise there was no way to pass e.g. `--features tracing` just to the `cargo` commands issued on the root repository:
CARGO_EXTRA_FLAGS applies the flags to the "cargo-miri" crate, too, which does not make sense for crate-specific features.
Fix install_to_sysroot doing path concatenation twice. Since the second concatenation was against an absolute path, it didn't do anything. This also makes the interface of install_to_sysroot() similar to that of cargo_cmd().
Implement --features for clippy, also fix not passing features to one of the cargo invocations for test
Enable automatic cross-compilation in run-make tests
Supersedes rust-lang/rust#138066.
Blocker for rust-lang/rust#141856.
Based on rust-lang/rust#138066 plus `rustdoc()` cross-compile changes.
### Summary
This PR automatically specifies `--target` to `rustc()` and `rustdoc()` to have `rustc`/`rustdoc` produce cross-compiled artifacts in run-make tests by default, unless:
- `//@ ignore-cross-compile` is used, or
- `bare_{rustc,rustdoc}` are used, or
- Explicit `.target()` is specified, which overrides the default cross-compile target.
Some tests are necessarily modified:
- Tests that have `.target(target())` have that incantation removed (since this is now automatically the default).
- Some tests have `//@ needs-target-std`, but are a necessary-but-insufficient condition, and are changed to `//@ ignore-cross-compile` instead as host-only tests.
- A few tests received `//@ ignore-musl` that fail against `x86_64-unknown-linux-musl` because of inability to find `-lunwind`. AFAICT, they don't *need* to test cross-compiled artifacts.
- Some tests are constrained to host-only for now, because the effort to make them pass on cross-compile does not seem worth the complexity, and it's not really *meaningfully* improving test coverage.
try-job: dist-various-1
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#140247 (Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs)
- rust-lang/rust#142507 (use `#[align]` attribute for `fn_align`)
- rust-lang/rust#142524 (Weekly `cargo update`)
- rust-lang/rust#142606 (AsyncDrop trait without sync Drop generates an error)
- rust-lang/rust#142639 (Add a missing colon at the end of the panic location details in location-detail-unwrap-multiline.rs)
- rust-lang/rust#142654 (library: Increase timeout on mpmc test to reduce flakes)
- rust-lang/rust#142692 (Assorted bootstrap cleanups (step 3))
r? `@ghost`
`@rustbot` modify labels: rollup
Assorted bootstrap cleanups (step 3)
I keep failing to unwrap the gordic knot of the logic of checking tools in bootstrap 😖 So in the meantime I at least want to upstream some cleanups I did along the way.
Since some time ago, we have separate steps for Clippy, so it shouldn't ever happen again that the check steps would be invoked with `builder.kind == Clippy`.
r? `@jieyouxu`
use `#[align]` attribute for `fn_align`
Tracking issue: https://github.com/rust-lang/rust/issues/82232https://github.com/rust-lang/rfcs/pull/3806 decides to add the `#[align]` attribute for alignment of various items. Right now it's used for functions with `fn_align`, in the future it will get more uses (statics, struct fields, etc.)
(the RFC finishes FCP today)
r? `@ghost`
{aarch64,x86_64}-pc-windows-gnullvm: build host tools
This is a temporary single-release workflow to create stage0 for these targets.
I opted for bootstrapping from Linux because that's the easiest host system to work with, but once this hits beta, having dedicated Windows runners would be sensible and probably preferable.
`--enable-full-tools` for whatever reason doesn't seem to work when cross-compiling, because LLVM tools for the new hosts are not copied into the expected directory.
https://github.com/rust-lang/compiler-team/issues/877
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#135656 (Add `-Z hint-mostly-unused` to tell rustc that most of a crate will go unused)
- rust-lang/rust#138237 (Get rid of `EscapeDebugInner`.)
- rust-lang/rust#141614 (lint direct use of rustc_type_ir )
- rust-lang/rust#142123 (Implement initial support for timing sections (`--json=timings`))
- rust-lang/rust#142377 (Try unremapping compiler sources)
- rust-lang/rust#142674 (remove duplicate crash test)
r? `@ghost`
`@rustbot` modify labels: rollup
Implement initial support for timing sections (`--json=timings`)
This PR implements initial support for emitting high-level compilation section timings. The idea is to provide a very lightweight way of emitting durations of various compilation sections (frontend, backend, linker, or on a more granular level macro expansion, typeck, borrowck, etc.). The ultimate goal is to stabilize this output (in some form), make Cargo pass `--json=timings` and then display this information in the HTML output of `cargo build --timings`, to make it easier to quickly profile "what takes so long" during the compilation of a Cargo project. I would personally also like if Cargo printed some of this information in the interactive `cargo build` output, but the `build --timings` use-case is the main one.
Now, this information is already available with several other sources, but I don't think that we can just use them as they are, which is why I proposed a new way of outputting this data (`--json=timings`):
- This data is available under `-Zself-profile`, but that is very expensive and forever unstable. It's just a too big of a hammer to tell us the duration it took to run the linker.
- It could also be extracted with `-Ztime-passes`. That is pretty much "for free" in terms of performance, and it can be emitted in a structured form to JSON via `-Ztime-passes-format=json`. I guess that one alternative might be to stabilize this flag in some form, but that form might just be `--json=timings`? I guess what we could do in theory is take the already emitted time passes and reuse them for `--json=timings`. Happy to hear suggestions!
I'm sending this PR mostly for a vibeck, to see if the way I implemented it is passable. There are some things to figure out:
- How do we represent the sections? Originally I wanted to output `{ section, duration }`, but then I realized that it might be more useful to actually emit `start` and `end` events. Both because it enables to see the output incrementally (in case compilation takes a long time and you read the outputs directly, or Cargo decides to show this data in `cargo build` some day in the future), and because it makes it simpler to represent hierarchy (see below). The timestamps currently emit microseconds elapsed from a predetermined point in time (~start of rustc), but otherwise they are fully opaque, and should be only ever used to calculate the duration using `end - start`. We could also precompute the duration for the user in the `end` event, but that would require doing more work in rustc, which I would ideally like to avoid :P
- Do we want to have some form of hierarchy? I think that it would be nice to show some more granular sections rather than just frontend/backend/linker (e.g. macro expansion, typeck and borrowck as a part of the frontend). But for that we would need some way of representing hierarchy. A simple way would be something like `{ parent: "frontend" }`, but I realized that with start/end timestamps we get the hierarchy "for free", only the client will need to reconstruct it from the order of start/end events (e.g. `start A`, `start B` means that `B` is a child of `A`).
- What exactly do we want to stabilize? This is probably a question for later. I think that we should definitely stabilize the format of the emitted JSON objects, and *maybe* some specific section names (but we should also make it clear that they can be missing, e.g. you don't link everytime you invoke `rustc`).
The PR be tested e.g. with `rustc +stage1 src/main.rs --json=timings --error-format=json -Zunstable-options` on a crate without dependencies (it is not easy to use `--json` with stock Cargo, because it also passes this flag to `rustc`, so this will later need Cargo integration to be usable with it).
Zulip discussions: [#t-compiler > Outputting time spent in various compiler sections](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Outputting.20time.20spent.20in.20various.20compiler.20sections/with/518850162)
MCP: https://github.com/rust-lang/compiler-team/issues/873
r? ``@nnethercote``
Add `-Z hint-mostly-unused` to tell rustc that most of a crate will go unused
This hint allows the compiler to optimize its operation based on this assumption, in order to compile faster. This is a hint, and does not guarantee any particular behavior.
This option can substantially speed up compilation if applied to a large dependency where the majority of the dependency does not get used. This flag may slow down compilation in other cases.
Currently, this option makes the compiler defer as much code generation as possible from functions in the crate, until later crates invoke those functions. Functions that never get invoked will never have code generated for them. For instance, if a crate provides thousands of functions, but only a few of them will get called, this flag will result in the compiler only doing code generation for the called functions. (This uses the same mechanisms as cross-crate inlining of functions.) This does not affect `extern` functions, or functions marked as `#[inline(never)]`.
This option has already existed in nightly as `-Zcross-crate-inline-threshold=always` for some time, and has gotten testing in that form. However, this option is still unstable, to give an opportunity for wider testing in this form.
Some performance numbers, based on a crate with many dependencies having just *one* large dependency set to `-Z hint-mostly-unused` (using Cargo's `profile-rustflags` option):
A release build went from 4m07s to 2m04s.
A non-release build went from 2m26s to 1m28s.
Clarify bootstrap tools description
The existence of `stage0-bootstrap-tools` suggests the possiblity of `stage1/N-bootstrap-tools`, but that's not really a thing. Also it doesn't fit the new bootstrap model, where `stageN` essentially means that it was built with a `stageN-1` compiler (except for std).
r? ``@jieyouxu``
Skip tidy triagebot linkcheck if `triagebot.toml` doesn't exist
Since distribution tarballs won't include `triagebot.toml`.
I think it's sufficiently obvious if `triagebot.toml` gets deleted entirely in PRs.
r? Kobzol
Add `StepMetadata` to describe steps
This is used to replace the previous downcasting of executed steps, which wasn't very scalable. In addition to tests, we could also use the metadata e.g. for tracing.
r? ```@jieyouxu```
Actually take `--build` into account in bootstrap
I went back 20 *stable* versions of Rust and I couldn't find this flag actually being used. Despite some of our CI workflows actually set this flag (!).
I added destructuring of the flags to make sure that this doesn't happen again. It found one more duplicated CLI flag.
r? ```@jieyouxu```
Add spawn APIs for BootstrapCommand to support deferred command execution
This PR adds new deferred command support in the ExecutionContext and provides APIs to spawn commands and wait for their completion. This structure enables moving away from the start_process helper functions towards a more unified and reusable command execution flow.
r? ````@Kobzol````
Change __rust_no_alloc_shim_is_unstable to be a function
This fixes a long sequence of issues:
1. A customer reported that building for Arm64EC was broken: #138541
2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well.
3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data.
4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not).
5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning.
6. A customer then reported a similar warning when using `lld-link` (<https://github.com/rust-lang/rust/pull/140176#issuecomment-2872448443>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: #140954.
7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <https://github.com/rust-lang/rust/pull/140176#issuecomment-2881867433>. At that point, my original change was reverted (#141024) leaving Arm64EC broken yet again.
Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported.
Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not.
There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above.
There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics).
Build with this change applied BEFORE #140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205>
Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for #128602)
r? `@bjorn3`
cc `@jieyouxu`
Rewrite `inline` attribute parser to use new infrastructure and improve diagnostics for all parsed attributes
r? `@oli-obk`
This PR:
- creates a new parser for inline attributes
- creates consistent error messages and error codes between attribute parsers; inline and others
- as such changes a few error messages for other attributes to be (in my eyes) much more consistent
- tests ast-lowering lints introduced by rust-lang/rust#138164 since this is now useful for the first time
- Coalesce some useless error codes
Builds on top of rust-lang/rust#138164Closesrust-lang/rust#137950
