Handle win32 separator for cygwin paths
This PR handles a issue that cygwin actually supports Win32 path, so we need to handle the Win32 prefix and separaters.
r? `@mati865`
cc `@jeremyd2019`
~~Not sure if I should handle the prefix like the windows target... Cygwin *does* support win32 paths directly going through the APIs, but I think it's not the recommended way.~~
Here I just use `cygwin_conv_path` because it handles both cygwin and win32 paths correctly and convert them into absolute POSIX paths.
UPDATE: Windows path prefix is handled.
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`
library: Increase timeout on mpmc test to reduce flakes
This recently spuriously failed in a rollup, so I think we can afford to increase the base timeout and the amount of time slept for to provide a much wider margin for the timeout to be reached.
Add a missing colon at the end of the panic location details in location-detail-unwrap-multiline.rs
The `location-detail-unwrap-multiline` test was failing when trying to enable `aarch64-pc-windows-msvc` CI Runners: https://github.com/rust-lang/rust/pull/140136#issuecomment-2978175728
When debugging, the normalized stderr was:
```
thread 'main' panicked at $DIR/location-detail-unwrap-multiline.rs:11:10:
called `Option::unwrap()` on a `None` value
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```
Note the trailing colon at the end of the location details in the panic message. This was missing in the error pattern regex. No idea why it has been passing for all other targets and failed for `aarch64-pc-windows-msvc`, but with the trailing colon it is now passing for all.
AsyncDrop trait without sync Drop generates an error
When type implements `AsyncDrop` trait, it must also implement sync `Drop` trait to be used in sync context and unwinds.
This PR adds error generation in such a case.
Fixes: rust-lang/rust#140696
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`
Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs
Fixesrust-lang/rust#108491Fixesrust-lang/rust#125879
This was due to updating inhabited predicate stuff which I had to do to make constructing ADTs with IATs in fields not ICE
Fixesrust-lang/rust#136678 (but no test added, I don't rly care about weird IAT edge cases under GCE)
Fixesrust-lang/rust#138131
Avoids doing "fully correct" candidate selection for IATs during hir ty lowering when in item signatures as it almost always leads to a query cycle from trying to build a `ParamEnv`. I replaced it with a use `DeepRejectCtxt` which should be able to handle this kind of conservative "could these types unify" while in a context where we don't want to do type equality.
This is a relatively simple scheme and should be forwards compatible with doing something more complex/powerful.
I'm not really sure how this interacts with rust-lang/rust#126651, though I'm also not really sure its super important to support projecting IATs from IAT self types given we don't even support `T::Assoc::Other` for trait-associated types so didn't give much thought to how this might fit in with that.
r? `@compiler-errors`
cc `@fmease`
{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
remove duplicate crash test
I noticed near duplication between "library/alloctests/tests/testing/crash_test.rs" and "library/alloctests/testing/crash_test.rs" and wanted to try and remove that. The only difference is the path used to import `Debug`, but it seems not to matter. Perhaps my change is still wrong?
r? ```@bjorn3```
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``
lint direct use of rustc_type_ir
cc rust-lang/rust#138449
As previously discussed with `@lcnr,` it is a lint to prevent direct use of rustc_type_ir, except for some internal crates (like next_trait_solver or rustc_middle for example).
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.
remove duplicate crash test
I noticed near duplication between "library/alloctests/tests/testing/crash_test.rs" and "library/alloctests/testing/crash_test.rs" and wanted to try and remove that. The only difference is the path used to import `Debug`, but it seems not to matter. Perhaps my change is still wrong?
r? ``@bjorn3``
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
remove joboet from review rotation
I've been very busy recently and this has led to reviews feeling less like fun and more like an additional chore – in short: I need a break. I'm still around though and am happy to review PRs explicitly assigned to me.
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````
CodeGen: rework Aggregate implemention for rvalue_creates_operand cases
A non-trivial refactor pulled out from rust-lang/rust#138759
r? workingjubilee
The previous implementation I'd written here based on `index_by_increasing_offset` is complicated to follow and difficult to extend to non-structs.
This changes the implementation, without actually changing any codegen (thus no test changes either), to be more like the existing `extract_field` (<2b0274c71d/compiler/rustc_codegen_ssa/src/mir/operand.rs (L345-L425)>) in that it allows setting a particular field directly.
Notably I've found this one much easier to get right, in particular because having the `OperandRef<Result<V, Scalar>>` gives a really useful thing to include in ICE messages if something did happen to go wrong.
Affirm `-Cforce-frame-pointers=off` does not override
This PR exists to document that we (that is, the compiler reviewer) implicitly made a decision in rust-lang/rust#86652 that defies the expectations of some programmers. Some programmers believe `-Cforce-frame-pointers=false` should obey the programmer in all cases, forcing the compiler to avoid generating frame pointers, even if the target specification would indicate they must be generated. However, many targets rely on frame pointers for fast or sound unwinding.
T-compiler had a weekly triage meeting on 2025-05-22. This topic was put to discussion because some programmers may expect the target-overriding behavior. In that meeting we decided removing frame pointers, at least with regards to the contract of the `-Cforce-frame-pointers` option, is not required, even if `=off` is passed, and that we will not do so if the target would expect them. This follows from the documentation here: https://doc.rust-lang.org/rustc/codegen-options/index.html#force-frame-pointers
We may separately pursue trying to clarify the situation more emphatically in our documentation, or warn when people pass the option when it doesn't do anything.
This commit adds a lint to prevent the use of rustc_type_ir in random
compiler crates, except for type system internals traits, which are
explicitly allowed. Moreover, this fixes diagnostic_items() to include
the CRATE_OWNER_ID, otherwise rustc_diagnostic_item attribute is ignored
on the crate root.
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`
