Shorten some dependency chains in the compiler
(I recommend reviewing this commit by commit.)
One of the long dependency chains in the compiler is:
- Many things depend on `rustc_errors`.
- `rustc_errors` depended on many things prior to this PR, including `rustc_target`, `rustc_type_ir`, `rustc_hir`, and `rustc_lint_defs`.
- `rustc_lint_defs` depended on `rustc_hir` prior to this PR.
- `rustc_hir` depends on `rustc_target`.
- `rustc_target` is large and takes a while.
This PR breaks that chain, through a few steps:
- The `IntoDiagArgs` trait, from `rustc_errors`, moves earlier in the dependency chain. This allows `rustc_errors` to stop depending on a pile of crates just to implement `IntoDiagArgs` for their types.
- Split `rustc_hir_id` out of `rustc_hir`, so crates that just need `HirId` and similar don't depend on all of `rust_hir` (and thus `rustc_target`).
- Make `rustc_lint_defs` stop depending on `rustc_hir`.
fix(debuginfo): handle false positives in overflow check
Fixesrust-lang/rust#144636.
Duplicate wrappers and normal recursive types can lead to false positives.
```rust
struct Recursive {
a: Box<Box<Recursive>>,
}
```
The ADT stack can be:
- `Box<Recursive>`
- `Recursive`
- `Box<Box<Recursive>>` (`Box` now detected as expanding)
We can filter them out by tracing the generic arg back through the stack, as true expanding recursive types must have their expanding arg used as generic arg throughout.
r? ````@wesleywiser````
Add new `--test-codegen-backend` bootstrap option
This new bootstrap command line flag allows to do:
```shell
./x.py test tests/ui/intrinsics/panic-uninitialized-zeroed.rs --stage 1 -j8 --test-codegen-backend gcc
```
This is the last step before running it into the CI.
Supersedes rust-lang/rust#144687.
r? ``````@Kobzol``````
Defer tail call ret ty equality to check_tail_calls
Fixesrust-lang/rust#144892.
Currently the tail call signature check assumes that return types have been accounted for. However, this is not complete for several reasons.
Firstly, we were using subtyping instead of equality in the HIR typeck code:
e1b9081e69/compiler/rustc_hir_typeck/src/expr.rs (L1096)
We could fix this, but it doesn't really do much for us anyways since HIR typeck doesn't care about regions.
That means, secondly, we'd need to fix the terminator type check in MIR typeck to account for variances, since tail call terminators need to relate their arguments invariantly to account for the "signature must be equal" rule. This seems annoying.
All of this seems like a lot of work, and we already are *manually* checking argument equality. Let's just extend the `check_tail_calls` to account for mismatches in return types anyways.
r? ``````@WaffleLapkin``````
Tell LLVM about read-only captures
`&Freeze` parameters are not only `readonly` within the function, but any captures of the pointer can also only be used for reads. This can now be encoded using the `captures(address, read_provenance)` attribute.
`rustc_lint_defs` uses `rustc_hir` solely for the `Namespace` type,
which it only needs the static description from. Use the static
description directly, to eliminate the dependency on `rustc_hir`.
This reduces a long dependency chain:
- Many things depend on `rustc_errors`
- `rustc_errors` depends on `rustc_lint_defs`
- `rustc_lint_defs` depended on `rustc_hir` prior to this commit
- `rustc_hir` depends on `rustc_target`
Some crates depend on `rustc_hir` but only want `HirId` and similar id
types. `rustc_hir` is a heavy dependency, since it pulls in
`rustc_target`. Split these types out into their own crate
`rustc_hir_id`.
This allows `rustc_errors` to drop its direct dependency on `rustc_hir`.
(`rustc_errors` still depends on `rustc_hir` indirectly through
`rustc_lint_defs`; a subsequent commit will fix that.)
`rustc_errors` depends on numerous crates, solely to implement its
`IntoDiagArg` trait on types from those crates. Many crates depend on
`rustc_errors`, and it's on the critical path.
We can't swap things around to make all of those crates depend on
`rustc_errors` instead, because `rustc_errors` would end up in
dependency cycles.
Instead, move `IntoDiagArg` into `rustc_error_messages`, which has far
fewer dependencies, and then have most of these crates depend on
`rustc_error_messages`.
This allows `rustc_errors` to drop dependencies on several crates,
including the large `rustc_target`.
(This doesn't fully reduce dependency chains yet, as `rustc_errors`
still depends on `rustc_hir` which depends on `rustc_target`. That will
get fixed in a subsequent commit.)
The capture of i in assert_ne!() is now known read-only, which
enables early SROA. Block this by passing i to println, where
we currently cannot recognize this.
`&Freeze` parameters are not only `readonly` within the function,
but any captures of the pointer can also only be used for reads.
This can now be encoded using the `captures(address, read_provenance)`
attribute.
Fix rustc uplifting (take two)
The rustc uplifting logic is really annoying.. https://github.com/rust-lang/rust/pull/145557 was not enough to fix it.
Consider https://github.com/rust-lang/rust/issues/145534#issuecomment-3201868888: in this situation, we do a stage3 build of a cross-compiled rustc (it happens because we run `x test --stage 2`, which mistakenly builds a stage3 rustc, but it doesn't matter what casuses it, what matters is that the stage3 build isn't working).
Currently, a stage3 cross-compiled build of rustc works like this:
1) stage0 (host) -> stage1 (host)
2) stage1 (host) -> stage2 (host)
3) stage2 (host) -> stage3 (target)
The problem is that in the uplifting logic, I assumed that we will have a stage2 (target) rustc available, which we can uplift. And that would indeed be an ideal solution. But currently, we will actually build a stage2 (*host*) rustc, and only then start the cross-compilation. So the uplifting is broken.
I spend a couple of hours trying to fix this, and do the uplifting "from the other direction", so that already when we assemble a stage3 rustc, we notice that an uplift should happen, and we only build stage1 (host) rustc, which also helps avoid one needless rustc build. However, this was relatively complicated and would require larger changes that I was not confident landing at this time.
So instead I decided to do a much simpler fix, and just disable rustc uplifting when cross-compiling. Since we currently do the `stage2 (host) -> stage3 (target)` step, it should not actually affect stage3 cross-compiled builds in any way (I hope..), and should only affect stage4+ builds, about which I don't really care (the only change there should be more rustc builds). For normal builds, the stage2 host rustc should (hopefully) always be present, so we shouldn't run into this issue.
Eventually, I would like to remove rustc uplifting completely. However, `x test --stage 2` on CI still currently builds a stage3 rustc for some reason, and if we removed uplifting completely, even for non-cross-compiled builds, that would cause an additional rustc build, and that's not great. So for now let's just allow uplifting for non-cross-compiled builds.
Fixesrust-lang/rust#145534.
r? `@jieyouxu`
Rollup of 13 pull requests
Successful merges:
- rust-lang/rust#139357 (Fix parameter order for `_by()` variants of `min` / `max`/ `minmax` in `std::cmp`)
- rust-lang/rust#140314 (Rustdoc: typecheck scrape-examples.js)
- rust-lang/rust#140794 (mention lint group in default level lint note)
- rust-lang/rust#145006 (Clarify EOF handling for `BufRead::skip_until`)
- rust-lang/rust#145252 (Demote x86_64-apple-darwin to Tier 2 with host tools)
- rust-lang/rust#145359 (Fix bug where `rustdoc-js` tester would not pick the right `search.js` file if there is more than one)
- rust-lang/rust#145381 (Implement feature `int_lowest_highest_one` for integer and NonZero types)
- rust-lang/rust#145417 (std_detect: RISC-V platform guide documentation)
- rust-lang/rust#145531 (Add runtime detection for APX-F and AVX10)
- rust-lang/rust#145619 (`std_detect`: Use `rustc-std-workspace-*` to pull in `compiler-builtins`)
- rust-lang/rust#145622 (Remove the std workspace patch for `compiler-builtins`)
- rust-lang/rust#145623 (Pretty print the name of an future from calling async closure)
- rust-lang/rust#145626 (add a fallback implementation for the `prefetch_*` intrinsics )
r? `@ghost`
`@rustbot` modify labels: rollup
add a fallback implementation for the `prefetch_*` intrinsics
related ACP: https://github.com/rust-lang/libs-team/issues/638
The fallback is to just ignore the arguments. That is a valid implementation because this intrinsic is just a hint.
I also added the `miri::intrinsic_fallback_is_spec` annotation, so that miri now supports these operations. A prefetch intrinsic call is valid on any pointer. (specifically LLVM guarantees this https://llvm.org/docs/LangRef.html#llvm-prefetch-intrinsic)
Next, I made the `LOCALITY` argument a const generic. That argument must be const (otherwise LLVM crashes), but that was not reflected in the type.
Finally, with these changes, the intrinsic can be safe and `const` (a prefetch at const evaluation time is just a no-op).
cc `@Amanieu`
r? `@RalfJung`
Pretty print the name of an future from calling async closure
Fixes https://github.com/rust-lang/rust/issues/145606 by introducing a way to customize the path rendering of async closures' futures in the pretty printer API.
Remove the std workspace patch for `compiler-builtins`
All dependencies of `std` have dropped the crates.io dependency on `compiler-builtins`, so this patch is no longer needed.
Closes: RUST-142265
`std_detect`: Use `rustc-std-workspace-*` to pull in `compiler-builtins`
https://github.com/rust-lang/rust/pull/145489 changed `std_detect` to no
longer depend on `cfg-if`, which meant it no longer indirectly pulled in
`rustc-std-workspace-core` via `cfg-if`. That caused it to no longer
depend on `compiler-builtins`.
Change `std_detect` to use `rustc-std-workspace-core` and
`rustc-std-workspace-alloc`, to integrate with the rustc workspace. This
also pulls in `compiler-builtins` via `rustc-std-workspace-core`.
Closes: https://github.com/rust-lang/rust/issues/145594
Add runtime detection for APX-F and AVX10
This was missed in rust-lang/rust#139534 and rust-lang/rust#139675
`@rustbot` label O-x86_64 O-x86_32 A-target-feature
r? `@Amanieu`
std_detect: RISC-V platform guide documentation
This is practically a revert of a revert, making the commit e907456b2e10622ccd854a3bba8d02ce170b5dbb on `stdarch` come around again with minor fixes, enhancements and adjustments.
An excerpt from the original commit message follows:
Since there's no architectural feature detection on RISC-V (unlike `CPUID` on x86 architectures and some system registers on Arm/AArch64), runtime feature detection entirely depends on the platform-specific facility.
As a result, availability of each feature heavily depends on the platform and its version.
To help users make a decision for feature checking on a RISC-V system, this commit adds a platform guide with minimum supported platform versions.
Implement feature `int_lowest_highest_one` for integer and NonZero types
Tracking issue: rust-lang/rust#145203
Implement the accepted ACP rust-lang/rust#145203 for methods that find the index of the least significant (lowest) and most significant (highest) set bit in an integer for signed, unsigned, and NonZero types.
Also add unit tests for all these types.
Fix bug where `rustdoc-js` tester would not pick the right `search.js` file if there is more than one
It happened to me quite a few times recently when I worked on the search index:
1. I make a change in search.js
2. I run `rustdoc-js` tests
3. nothing changes
So my solution was to simply remove the folder, but it's really suboptimal. With this PR, it now picks the most recently modified file.
cc ```@lolbinarycat```
Demote x86_64-apple-darwin to Tier 2 with host tools
Switch to only using aarch64 runners (implying we are now cross-compiling) and stop running tests. In the future, we could enable (some?) tests via Rosetta 2.
This implements the decision from https://github.com/rust-lang/rfcs/pull/3841.
Clarify EOF handling for `BufRead::skip_until`
This aligns `BufRead::skip_until`'s description more with `BufRead::read_until` in terms of how it handles EOF and extends the doctest to include this behavior.
mention lint group in default level lint note
### Summary
This PR updates lint diagnostics so that default-level notes now mention the lint group they belong to, if any.
Fixes: rust-lang/rust#65464.
### Example
```rust
fn main() {
let x = 5;
}
```
Before:
```
= note: `#[warn(unused_variables)]` on by default
```
After:
```
= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default
```
### Unchanged Cases
Messages remain the same when the lint level is explicitly set, e.g.:
* Attribute on the lint `#[warn(unused_variables)]`:
```
note: the lint level is defined here
LL | #[warn(unused_variables)]
| ^^^^^^^^^^^^^^^^
```
* Attribute on the group `#[warn(unused)]:`:
```
= note: `#[warn(unused_variables)]` implied by `#[warn(unused)]`
```
* CLI option `-W unused`:
```
= note: `-W unused-variables` implied by `-W unused`
= help: to override `-W unused` add `#[allow(unused_variables)]`
```
* CLI option `-W unused-variables`:
```
= note: requested on the command line with `-W unused-variables`
```
Rustdoc: typecheck scrape-examples.js
more typechecking progress, this time we're mostly held back by the fact that `document.querySelectorAll` can't return nice types if its given a compound query (see the issue linked in a code comment).
Additionally, it seems like the generated `data-locs` attribute has fields that are never used by anything?
r? ```@notriddle```
Fix parameter order for `_by()` variants of `min` / `max`/ `minmax` in `std::cmp`
We saw a regression introduced in version `1.86` that seems to be coming from switching the order of `v1` and `v2` when calling `comparison` functions in `min_by` / `max_by` / `minmax_by` (cf. this PR: https://github.com/rust-lang/rust/pull/136307)
When the `compare` function is not symmetric in the arguments, this leads to false results. Apparently, the test cases do not cover this scenario currently. While asymmetric comparison may be an edge case, but current behavior is unexpected nevertheless.
The fallback is to just ignore the arguments. That is a valid implementation because this intrinsic is just a hint.
I also added `miri::intrinsic_fallback_is_spec` annotation, so that miri now supports these operations. A prefetch intrinsic call is valid on any pointer.
https://github.com/rust-lang/rust/pull/145489 changed `std_detect` to no
longer depend on `cfg-if`, which meant it no longer indirectly pulled in
`rustc-std-workspace-core` via `cfg-if`. That caused it to no longer
depend on `compiler-builtins`.
Change `std_detect` to use `rustc-std-workspace-core` and
`rustc-std-workspace-alloc`, to integrate with the rustc workspace. This
also pulls in `compiler-builtins` via `rustc-std-workspace-core`.
Closes: https://github.com/rust-lang/rust/issues/145594
