Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#148165 (Use `mut` less in dataflow analysis)
- rust-lang/rust#148287 (Fix deferred cast checks using the wrong body for determining constness)
- rust-lang/rust#148317 (bootstrap: Extract parts of `bootstrap::core::builder` into a `cli_paths` module)
r? `@ghost`
`@rustbot` modify labels: rollup
bootstrap: Extract parts of `bootstrap::core::builder` into a `cli_paths` module
One of the things that makes bootstrap's CLI path handling hard to work with is the fact that it's in the middle of a ~2000 line file full of all sorts of other things. And the primary code sequence is in an unhelpfully-named `StepDescription::run` function.
This PR therefore pulls some key chunks of code out into a `cli_paths` submodule.
This should be a purely non-functional change.
Fix deferred cast checks using the wrong body for determining constness
re-introduces https://github.com/rust-lang/rust/pull/103683
it was lost in 4fec845c3f
deferred checks possibly have more such issues, needs investigation.
r? `@fee1-dead`
Use `mut` less in dataflow analysis
`&mut Analysis` is used a lot:
- In results visitors, even though only one visitor needs mutability.
- In all the `apply_*` methods, even though only one visitor needs mutability.
I've lost track of the number of times I've thought "why are these `mut` again?" and had to look through the code to remind myself. It's really unexpected, and most `Analysis` instances are immutable, because the `state` values are what get mutated.
This commit introduces `RefCell` in one analysis and one results visitor. This then lets another existing `RefCell` be removed, and a ton of `&mut Analysis` arguments become `&Analysis`. And then `Analysis` and `Results` can be recombined.
r? `@cjgillot`
Adjust successor iterators.
Because rust-lang/rust#148054 was a slight perf regression.
The problem was seemingly because this iterator structure:
```
slice_iter.chain(Option_iter.chain(Option_iter))
```
changed to this:
```
slice_iter.chain(Option_iter).chain(Option_iter)
```
The commit also tweaks the `slice_iter` part, changing `into_iter` to `iter` and using `[]` instead of `(&[])`, for conciseness and consistency.
r? `@saethlin`
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#144291 (Constify trait aliases)
- rust-lang/rust#147633 (Add new `--bypass-ignore-backends` option)
- rust-lang/rust#148252 (Improve diagnose for unconditional panic when resource limit)
- rust-lang/rust#148262 (Fix types being marked as dead when they are inferred generic arguments)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix types being marked as dead when they are inferred generic arguments
Previously usages of a type in a pattern were ignored. This is incorrect, since if the type is in a pattern we're clearly producing it in the expression we're matching against.
I think this `in_pat` check was meant to be only for variants, which we should indeed ignore since we can just remove the match arm that matches the pattern. Please double check my logic here since this is my first time touching the dead-code pass and I'm not 100% sure this is what the `self.in_pat` check was for.
Fixes https://github.com/rust-lang/rust/issues/148144
Improve diagnose for unconditional panic when resource limit
Improve diagnostic message for similar issue rust-lang/rust#115021.
When `parallel_compiler=true`, the Rust compiler frontend sets `-Z threads` to match the number of cores, which is reasonable and common. However, in a constrained environment or with an excessive number of cores (such as 377 mentioned below 😑), it could consume all resources and cause a panic.
Setting a default maximum for `-Z threads` in a parallel compiler is challenging. However, the panic error message can guide the user to check the system limit and explicitly lower the thread count according to their needs.
```
14:55:47 thread 'main' panicked at /rustc/f1586001ace26df7cafeb6534eaf76fb2c5513e5/compiler/rustc_interface/src/util.rs:216:18:
14:55:47 called `Result::unwrap()` on an `Err` value: ThreadPoolBuildError { kind: IOError(Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }) }
...
14:55:47 note: compiler flags: --crate-type lib -C opt-level=z -C embed-bitcode=no -C linker=/cache/84996/rust-sdk/target/shim/aarch64-unknown-linux-ohos/clang -Z unstable-options -C symbol-mangling-version=v0 -Z panic-in-drop=abort -C codegen-units=1 -C debuginfo=1 -C embed-bitcode=yes -Z threads=377 -C link-arg=-Wl,--build-id=sha1 -Z binary-dep-depinfo
```
Add new `--bypass-ignore-backends` option
Fixes https://github.com/rust-lang/rust/issues/147063.
It adds a new option to `bootstrap` to allow to ignore `//@ ignore-backends` statements in tests.
cc ```@jieyouxu``` ```@antoyo```
r? ```@Kobzol```
Constify trait aliases
Allow `const trait Foo = Bar + [const] Baz;` trait alias declarations. Their rules are the same as with super traits of const traits. So `[const] Baz` or `const Baz` is only required for `[const] Foo` or `const Foo` bounds respectively.
tracking issue rust-lang/rust#41517 (part of the general trait alias feature gate, but I can split it out into a separate const trait alias feature gate. I just assumed that const traits would stabilize before trait aliases, and we'd want to stabilize trait aliases together with const trait aliases at the same time)
r? ``@compiler-errors`` ``@fee1-dead``
Revert "Auto merge of #146186 - dpaoliello:cc, r=jieyouxu"
This reverts https://github.com/rust-lang/rust/pull/146186. This will mean regressing whichever `cc` fixes were needed for
> fixes when compiling the Rust compiler for Arm64EC.
It's not clear which `cc` change causes the across-the-board perf regression, I suspect it's a change in how certain compiler flags are handed. But I can immediately tell this is a rabbit hole to investigate, so let's revert for now to return-to-baseline and alleviate time pressure.
Allow check builds with binaries for the dummy codegen backend
This is likely the last part necessary for https://github.com/rust-lang/miri/pull/4648. Miri needs to be able to do a regular check build for compile_fail doc tests to work.
Move wasm `throw` intrinsic back to `unwind`
Fixesrust-lang/rust#148246, less invasive than the previously proposed rust-lang/rust#148269. Removes the publicly visible unstable intrinsic tracked in rust-lang/rust#122465 since it's not clear how to export it in a sound manner.
r? `@bjorn3`
---
rustc assumes that regular `extern "Rust"` functions unwind only if the `unwind` panic runtime is linked. `throw` was annotated as such, but unwound unconditionally. This could cause UB when a crate built with `-C panic=abort` called `throw` from `core` built with `-C panic=unwind`, since no terminator was added to handle the panic arising from calling an allegedly non-unwinding `extern "Rust"` function.
rustc was taught to recognize this condition since https://github.com/rust-lang/rust/pull/144225 and prevented such linkage, but this caused regressions in
https://github.com/rust-lang/rust/issues/148246, since this meant that Emscripten projects could not be built with `-C panic=abort` without recompiling std.
The most straightforward solution would be to move `throw` into the `panic_unwind` crate, so that it's only compiled if the panic runtime is guaranteed to be `unwind`, but this is messy due to our architecture. Instead, move it into `unwind::wasm`, which is only compiled for bare-metal targets that default to `panic = "abort"`, rendering the issue moot.
rustc assumes that regular `extern "Rust"` functions unwind only if the
`unwind` panic runtime is linked. `throw` was annotated as such, but
unwound unconditionally. This could cause UB when a crate built with `-C
panic=abort` called `throw` from `core` built with `-C panic=unwind`,
since no terminator was added to handle the panic arising from calling an
allegedly non-unwinding `extern "Rust"` function.
rustc was taught to recognize this condition since
https://github.com/rust-lang/rust/pull/144225 and prevented such
linkage, but this caused regressions in
https://github.com/rust-lang/rust/issues/148246, since this meant that
Emscripten projects could not be built with `-C panic=abort` without
recompiling std.
The most straightforward solution would be to move `throw` into the
`panic_unwind` crate, so that it's only compiled if the panic runtime is
guaranteed to be `unwind`, but this is messy due to our architecture.
Instead, move it into `unwind::wasm`, which is only compiled for
bare-metal targets that default to `panic = "abort"`, rendering the
issue moot.
Align VEX V5 boot routine to 4 bytes
This PR fixes an alignment issue with the initialization routine on the VEX V5 target.
Previously, if the `.text` output section contained any functions aligned to more than four bytes, the linker would add padding bytes before the beginning of `.text` rather than changing the position of the aligned function inside the section itself. This is an issue because the entry point for the program needs to be located at `0x3800_0020` on this platform and the addition of padding could cause it to be moved.
To fix this, I've forced the start address of the `.text` section to be aligned to 4 bytes so that the entry point is placed consistently. Items inside the section can still be aligned to values larger than this.
Handle default features and -Ctarget-features in the dummy backend
This prevents a warning about ABI relevant target features not being set on x86 and arm. In addition it is required for miri to report correct features in is_*_feature_detected!() if miri switches to the dummy backend.
Required for https://github.com/rust-lang/miri/pull/4648
[rustdoc] Include attribute and derive macros when filtering on "macros"
As discussed [here](https://github.com/rust-lang/rust/pull/147909), some filters should have been "grouped". This PR allows attribute and derive macros to match the `macro` filter.
I'll wait for https://github.com/rust-lang/rust/pull/148005 to add more tests as it would require a proc-macro library for now.
r? ```@notriddle```
rustdoc: Rename unstable option `--nocapture` to `--no-capture` in accordance with `libtest`
Context: https://github.com/rust-lang/rust/issues/133073, https://github.com/rust-lang/rust/pull/139224 (TL;DR: `libtest` has soft-deprecated `--nocapture` in favor a new & stable `--no-capture`; we should follow suit).
Since the rustdoc flag is unstable (tracking issue: https://github.com/rust-lang/rust/issues/148116), we're allowed to remove the old flag immediately. However since the flag has existed for 4 years we could hard-deprecate the flag first or at least be considerate and provide a diagnostic referring users to the new flag. This PR does neither. Let me know what you would think would be best.
Cargo doesn't use this flag, not yet at least (https://github.com/rust-lang/cargo/pull/9705), so we really are free to sunset this flag without bigger consequences.
Simplify rustc_public context handling
We no longer need two thread-local variables to store the context. We used to have two because the conversion logic used to live in a separate crate from the rest of the business logic.
I'm also merging the Container struct and the CompilerInterface trait as a single struct. This removes the unnecessary indirection and code duplication. Using a trait would also block us from adding any generic method to the compiler interface.
r? ``@oli-obk``
cc: ``@makai410``
Micro-optimization attempt in coroutine layout computation
In `compute_layout`, there were a bunch of collections (`IndexVec`s) that were being created by `push`ing in a loop, instead of a, hopefully, more performant usage of iterator combinators. [Second commit](6f682c2774) is just a small cleanup.
I'd love a perf run to see if this shows up in benchmarks.
Turn `Cow::is_borrowed,is_owned` into associated functions.
This is done because `Cow` implements `Deref`. Therefore, to avoid conflicts with an inner type having a method of the same name, we use an associated method, like `Box::into_raw`.
Tracking issue: #65143
We no longer need two thread-local variables to store the context.
We used to have two because the conversion logic used to live in a
separate crate from the rest of the business logic.
I'm also removing the Container struct and replacing the
CompilerInterface trait with a struct. This removes the unnecessary
indirection and code duplication. Using a trait would also block us
from adding any generic method to the compiler interface.
This prevents a warning about ABI relevant target features not being set
on x86 and arm. In addition it is required for miri to report correct
features in is_*_feature_detected!() if miri switches to the dummy backend.
