Respect stage0 sysroot when compiling rmake.rs with COMPILETEST_FORCE_STAGE0
Context: <https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/stage0.20compiletest.20broken>.
> cg_clif uses `COMPILETEST_FORCE_STAGE0=1 ./x.py test --stage 0` for running the rustc test suite. With the introduction of rmake.rs this broke. `librun_make_support.rlib` is compiled using the bootstrap rustc wrapper which sets `--sysroot build/aarch64-unknown-linux-gnu/stage0-sysroot`, but then compiletest will compile `rmake.rs` using the sysroot of the bootstrap compiler causing it to not find the `libstd.rlib` against which `librun_make_support.rlib` is compiled.
cc ``@bjorn3``
Fixes#122196.
Split refining_impl_trait lint into _reachable, _internal variants
As discussed in https://github.com/rust-lang/rust/issues/119535#issuecomment-1909352040:
> We discussed this today in triage and developed a consensus to:
>
> * Add a separate lint against impls that refine a return type defined with RPITIT even when the trait is not crate public.
> * Place that in a lint group along with the analogous crate public lint.
> * Create an issue to solicit feedback on these lints (or perhaps two separate ones).
> * Have the warnings displayed with each lint reference this issue in a similar manner to how we do that today with the required `Self: '0'` bound on GATs.
> * Make a note to review this feedback on 2-3 release cycles.
This points users to https://github.com/rust-lang/rust/issues/121718 to leave feedback.
Bump windows-bindgen to 0.55.0
windows-bindgen is the crate used to generate std's Windows API bindings.
Not many changes for us, it's mostly just simplifying the generate code (e.g. no more `-> ()`). The one substantial change is some structs now use `i8` byte arrays instead of `u8`. However, this only impacts one test.
[BOLT] Use CDSort and CDSplit
CDSort and CDSplit are the most recent versions of function ordering and function splitting algorithms with some improvements over the previous baseline (ext-tsp and two-way splitting).
hir: Remove `opt_local_def_id_to_hir_id` and `opt_hir_node_by_def_id`
Also replace a few `hir_node()` calls with `hir_node_by_def_id()`.
Follow up to https://github.com/rust-lang/rust/pull/120943.
Rollup of 10 pull requests
Successful merges:
- #117118 ([AIX] Remove AixLinker's debuginfo() implementation)
- #121650 (change std::process to drop supplementary groups based on CAP_SETGID)
- #121764 (Make incremental sessions identity no longer depend on the crate names provided by source code)
- #122212 (Copy byval argument to alloca if alignment is insufficient)
- #122322 (coverage: Initial support for branch coverage instrumentation)
- #122373 (Fix the conflict problem between the diagnostics fixes of lint `unnecessary_qualification` and `unused_imports`)
- #122479 (Implement `Duration::as_millis_{f64,f32}`)
- #122487 (Rename `StmtKind::Local` variant into `StmtKind::Let`)
- #122498 (Update version of cc crate)
- #122503 (Make `SubdiagMessageOp` well-formed)
r? `@ghost`
`@rustbot` modify labels: rollup
more eagerly instantiate binders
The old solver sometimes incorrectly used `sub`, change it to explicitly instantiate binders and use `eq` instead. While doing so I also moved the instantiation before the normalize calls. This caused some observable changes, will explain these inline. This PR therefore requires a crater run and an FCP.
r? types
Various cleanups around the const eval query providers
r? `@RalfJung`
after this, working on running validation before interning starts with swapping the order of two lines of code
fix unsoundness in Step::forward_unchecked for signed integers
Fixes#122420
```rust
pub fn foo(a: i8, b: u8) -> i8 {
unsafe { a.checked_add_unsigned(b).unwrap_unchecked() }
}
```
still compiles down to a single arithmetic instruction ([godbolt](https://rust.godbolt.org/z/qsd3xYWfE)).
But we may be losing some loop optimizations if llvm can no longer easily derive that it's a finite counted loop from the no-wrapping flags.
interpret: ensure that Place is never used for a different frame
We store the address where the stack frame stores its `locals`. The idea is that even if we pop and push, or switch to a different thread with a larger number of frames, then the `locals` address will most likely change so we'll notice that problem. This is made possible by some recent changes by `@WaffleLapkin,` where we no longer use `Place` across things that change the number of stack frames.
I made these debug assertions for now, just to make sure this can't cost us any perf.
The first commit is unrelated but it's a one-line comment change so it didn't warrant a separate PR...
r? `@oli-obk`
compiletest: Allow `only-unix` in test headers
The header `ignore-unix` is already allowed. Also extend tests.
This is needed by https://github.com/rust-lang/rust/pull/121573 which I am splitting up into smaller and more digestible PRs.
miri: add some chance to reuse addresses of previously freed allocations
The hope is that this can help us find ABA issues.
Unfortunately this needs rustc changes so I can't easily run the regular benchmark suite. I used `src/tools/miri/tests/pass/float_nan.rs` as a substitute:
```
Before:
Benchmark 1: ./x.py run miri --stage 0 --args src/tools/miri/tests/pass/float_nan.rs --args --edition=2021
Time (mean ± σ): 9.570 s ± 0.013 s [User: 9.279 s, System: 0.290 s]
Range (min … max): 9.561 s … 9.579 s 2 runs
After:
Benchmark 1: ./x.py run miri --stage 0 --args src/tools/miri/tests/pass/float_nan.rs --args --edition=2021
Time (mean ± σ): 9.698 s ± 0.046 s [User: 9.413 s, System: 0.279 s]
Range (min … max): 9.666 s … 9.731 s 2 runs
```
That's a ~1.3% slowdown, which seems fine to me. I have seen a lot of noise in this style of benchmarking so I don't quite trust this anyway; we can make further experiments in the Miri repo after this migrated there.
r? `@oli-obk`
windows: remove support for slim rwlock
Since https://github.com/rust-lang/rust/pull/121956 we don't need it any more, and we are generally short on Windows staff so reducing the amount of code we have to test and maintain sounds like a good idea.
The InitOnce stuff is still used by `thread_local_key::StaticKey` on 64bit windows-gnu.
Update cargo
9 commits in a4c63fe5388beaa09e5f91196c86addab0a03580..7065f0ef4aa267a7455e1c478b5ccacb7baea59c
2024-03-06 22:15:17 +0000 to 2024-03-12 13:25:15 +0000
- chore: remove repetitive word (rust-lang/cargo#13575)
- refactor(lockfile): Make diffing/printing more reusable (rust-lang/cargo#13564)
- test: Add tests for using worktrees and sparse checkouts (rust-lang/cargo#13567)
- util/network/http: Use `cargo/1.2.3` user-agent header (rust-lang/cargo#13548)
- fix: Consistently compare MSRVs (rust-lang/cargo#13537)
- refactor(shell): Use alternate to close links (rust-lang/cargo#13562)
- fix(doc): Collapse down Generated statuses without --verbose (rust-lang/cargo#13557)
- doc: Add doc for -Zpublic-dependency (rust-lang/cargo#13556)
- docs: add link to the exported_private_dependencies lint (rust-lang/cargo#13547)
r? ghost
rustdoc: fix up old test
`tests/rustdoc/line-breaks.rs` had several issues:
1. It used `//`@count`` instead of `// `@count`` (notice the space!) which gets treated as a `ui_test` directive instead of a `htmldocck` one. `compiletest` didn't flag it as an error because it's allowlisted ([#121561](https://github.com/rust-lang/rust/pull/121561)) presumably precisely because of this test. And before the compiletest→ui_test migration, these directives must've been ignored, too, because …
2. … the checks themselves no longer work either: The count of `<br>`s is actually 0 in all 3 cases because – well – we no longer generate any `<br>`s inside `<pre>`s.
Since I don't know how to ``@count`` `\n`s instead of `<br>`s, I've turned them into ``@matches`.` Btw, I don't know if this test is still desirable or if we have other tests that cover this (I haven't checked).
r? rustdoc
Ensure nested allocations in statics neither get deduplicated nor duplicated
This PR generates new `DefId`s for nested allocations in static items and feeds all the right queries to make the compiler believe these are regular `static` items. I chose this design, because all other designs are fragile and make the compiler horribly complex for such a niche use case.
At present this wrecks incremental compilation performance *in case nested allocations exist* (because any query creating a `DefId` will be recomputed and never loaded from the cache). This will be resolved later in https://github.com/rust-lang/rust/pull/115613 . All other statics are unaffected by this change and will not have performance regressions (heh, famous last words)
This PR contains various smaller refactorings that can be pulled out into separate PRs. It is best reviewed commit-by-commit. The last commit is where the actual magic happens.
r? `@RalfJung` on the const interner and engine changes
fixes https://github.com/rust-lang/rust/issues/79738
