Skip to content

Rustc pull update - #2981

Merged
tshepang merged 42 commits into
mainfrom
rustc-pull
Aug 24, 2026
Merged

Rustc pull update#2981
tshepang merged 42 commits into
mainfrom
rustc-pull

Conversation

@workflows-rustc-dev-guide

Copy link
Copy Markdown

Latest update from rustc.

bors and others added 30 commits August 17, 2026 02:41
Overhaul `CoroutineKind`

Its structure is a bit weird. Details in individual commits.

r? @mejrs
Single-byte ASCII searcher for StrSearcherImpl(pattern.rs)

This adds a fast single-byte ASCII searcher using memchr. It will be useful when the user is searching for single ASCII tokens such as `\s`,`"`, `'`, `/`, `\n`, etc which are common usecase in many applications.

Benchmark results:
| Benchmark | Current stable | ByteNeedle PR | Δ |
|---|---|---|---|
| find_1byte_str_long_nomatch | 36,476 | 3,630 | **−90% (10.0×)** |
| find_1byte_str_long_match_end | 37,129 | 3,703 | **−90% (10.0×)** |
| rfind_1byte_str_long_nomatch | 35,653 | 3,542 | **−90% (10.1×)** |
| split_1byte_str_sparse | 40,289 | 14,555 | **−64% (2.8×)** |
| find_1byte_str_short_haystack | 16,970 | 8,140 | −52% (2.1×) |
| find_1byte_str_early_return | 16,860 | 10,571 | −37% (1.6×) |
| find_str | 6,265 | 5,630 | −10% |
| rfind_str | 5,623 | 5,206 | −7% |
| find_str_worst_case | 1,192 | 1,104 | −7% |
| split_char_dense | 39,598 | 37,823 | −4.5% |
| find_char_long_match_end | 3,766 | 3,625 | −3.7% |
| split_1byte_str_multibyte_haystack | 78,827 | 76,092 | −3.5% |
| find_char_short_haystack | 4,203 | 4,070 | −3% |
| find_char_long_nomatch | 3,726 | 3,629 | −2.6% |
| split_char_sparse | 13,128 | 12,927 | −1.5% |
| ends_with / starts_with (×4) | 272 | 275 | +1% |
| rfind_char_long_nomatch | 3,520 | 3,557 | +1% |
| rfind_str_worst_case | 27,056 | 27,432 | +1.4% |
| split_char_multibyte_haystack | 57,433 | 60,890 | **+6%** |
| split_1byte_str_dense | 45,841 | 52,936 | **+15%** |

r? joboet
`rust-analyzer` subtree update

Subtree update of `rust-analyzer` to rust-lang/rust-analyzer@bb3bbbd.

Created using https://github.com/rust-lang/josh-sync.

r? @ghost
…=Mark-Simulacrum

implement <IpAddr, SocketAddr>::unspecified_from()

Tracking issue: rust-lang/rust#158975
I went ahead with an initial implementation, since there are still two unresolved questions in the tracking issue.
…r=lcnr

Move `LateParamRegion` to `rustc_type_ir`

Move `LateParamRegion` to `rustc_type_ir`. As per feedback, I created a `TrivialLiftImpls!` mirroring `rustc_middle`'s variant which is creates an identity function for `lift_to_interner(...)`.

Spun off from; rust-lang/rust#160509

r? @lcnr
…imulacrum

Remove references to the obsolete `try-perf` branch

This is no longer needed after rust-lang/rustc-perf#2524.
rename `#[rustc_dump_predicates]` to `#[rustc_dump_clauses]`

Part of rust-lang/rust#107250 / Follow-up to rust-lang/rust#159990 (comment)

The attribute dumps `clauses_of` an item, so rename accordingly.

r? @oli-obk
Remove jdno from infra-ci rotation

Triagebot keeps assigning JD to infra PRs, but I don't think that he has been active in reviewing for the past few months. So I think it's better to remove him from the rotation, to avoid unnecessary rerolls.

CC @jdno

r? marcoieni
…uwer

Rollup of 12 pull requests

Successful merges:

 - rust-lang/rust#161221 (`rust-analyzer` subtree update)
 - rust-lang/rust#161232 (Subtree sync for rustc_codegen_cranelift)
 - rust-lang/rust#160058 (atomic volatile: add intrinsics)
 - rust-lang/rust#161206 (Library lock file update)
 - rust-lang/rust#160905 (implement <IpAddr, SocketAddr>::unspecified_from())
 - rust-lang/rust#160986 (Move `LateParamRegion` to `rustc_type_ir`)
 - rust-lang/rust#161145 (Remove references to the obsolete `try-perf` branch)
 - rust-lang/rust#161197 (citool: update rust crates)
 - rust-lang/rust#161225 (Add regression test for lint panic on nested generic with default type param)
 - rust-lang/rust#161229 (rustc_target: couple AArch64 LLVM and cfg pauthtest ABIs)
 - rust-lang/rust#161230 (rename `#[rustc_dump_predicates]` to `#[rustc_dump_clauses]`)
 - rust-lang/rust#161237 (Remove jdno from infra-ci rotation)
Treat vars created for opaque subtyping as live everywhere

Fixes rust-lang/rust#160669

r? lqd

Let's look at a minimal variant of rust-lang/rust#160669

```rust
fn minimal(short: (), out: &'static ()) -> impl Sized {
    if true {
        return &short; //~ ERROR `short` does not live long enough
    }
    out
}
```

That has the following (simplified) MIR:

```rust
fn foo(_1: (), _2: &'?4 ()) -> Opaque(DefId(foo::{opaque#0}), []) {
    bb0: { switchInt(move _4) -> [0: bb2, otherwise: bb1]; }

    bb1: {
        _0 = &'?2 _1; // bb1[0]
        goto -> bb3;
    }

    bb2: {
        _0 = &'?3 (*_2); // bb2[3]
        goto -> bb3;
    }

    bb3: {
        return;
    }
}
```

And the following region constraints:

<img width="236" height="583" alt="image" src="https://github.com/user-attachments/assets/4c450ccd-1c5c-4a9c-a4f1-0875cf0e5553" />

Note `'?5` and `'?6`: these don't show up in the MIR graph because they arise from the `enable_subtyping` closure in [`relate_opaques`](https://github.com/rust-lang/rust/blob/c9b7f178899788fac53d942b82cf97665ee59aaa/compiler/rustc_borrowck/src/type_check/relate_tys.rs#L116). Importantly (today), these regions are related to each other (and to other regions in hidden types) *at a single point*, but **are not live at any point**.

For NLL this is not a problem (since liveness does not matter for outlives constraint propagation. For Polonius, this is an issue.

The fix here is fairly simple: consider these lifetimes live at all points. This may be an *overestimate* of liveness, but this is all code that doesn't get called with the next solver.

This is also the same reason that this is not an issue with the next solver. Opaque types are normalized in HIR typeck, so these hacky regions are never created.

There are a couple alternative fixes that I think are ultimately not as good:

1) Equate the previous hidden type with the new hidden type using `Locations::All` - when [registering the goals](https://github.com/rust-lang/rust/blob/c9b7f178899788fac53d942b82cf97665ee59aaa/compiler/rustc_borrowck/src/type_check/relate_tys.rs#L161) from equating these two, force `Locations::All` instead of `Locations::Single`.
2) [**Equate all uses, not just the final defining use, in borrowck**](rust-lang/rust@59a4c62) - this has us store any duplicates in `insert_hidden_type`, which then get equated with the "expected" hidden type in `apply_definition_site_hidden_types` with `Locations::All`. I think this is fine, but a lot less "local" logic.

I'll note that for the next solver, we equate the hidden types with the return type in the signature with`Locations::Single`:

<img width="289" height="586" alt="image" src="https://github.com/user-attachments/assets/34d15820-06e3-4205-9278-e82465dca139" />

(note, this MIR is slightly different: `'5` is `short`'s lifetime; `'6` is the lifetime from the normalized opaque (`&'?6 ()`); `'4` is the renumbered lifetime for the MIR body)

Given that, perhaps (1) is the most faithful to the spirit of the next solver (that there is one hidden type that things get related to), but this seems like a *slightly* smaller-in-scope fix.

In any case, I think any solution here is mostly just a waiting game for the next solver.
Always statically link std into rustc_driver

This always statically links std into rustc_driver by removing the MinGW exception.

try-job: dist-x86_64-mingw
Revert "Rollup merge of #161006 - GuillaumeGomez:gcc-binutils, r=Kobzol"

This reverts PR rust-lang/rust#161006.

That fixes the mysterious Miri build issue on aarch64-linux:
```
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-Wl,--fix-cortex-a53-843419" "/home/runner/work/miri/miri/target/release/build/miri/cd7c7136867df99d/out/rustcCgh8cr/symbols.o" "<9 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic" "<sysroot>/lib/rustlib/aarch64-unknown-linux-gnu/lib/libtikv_jemalloc_sys-*.rlib" "/home/runner/work/miri/miri/target/release/build/miri/066391e6b2ce8aa3/out/libmiri-066391e6b2ce8aa3.rlib" "/home/runner/work/miri/miri/target/release/build/directories/839d79c0abf643b9/out/libdirectories-839d79c0abf643b9.rlib" "/home/runner/work/miri/miri/target/release/build/dirs-sys/85035a9d09d384eb/out/libdirs_sys-85035a9d09d384eb.rlib" "/home/runner/work/miri/miri/target/release/build/option-ext/f18695aec5c506ba/out/liboption_ext-f18695aec5c506ba.rlib" "/home/runner/work/miri/miri/target/release/build/libloading/839165948c6a5ee8/out/liblibloading-839165948c6a5ee8.rlib" "/home/runner/work/miri/miri/target/release/build/measureme/903cc8fb53ad83e3/out/libmeasureme-903cc8fb53ad83e3.rlib" "/home/runner/work/miri/miri/target/release/build/rustc-hash/e49345dfb31aa501/out/librustc_hash-e49345dfb31aa501.rlib" "/home/runner/work/miri/miri/target/release/build/parking_lot/885d4f925d9d80e5/out/libparking_lot-885d4f925d9d80e5.rlib" "/home/runner/work/miri/miri/target/release/build/parking_lot_core/3801e2f2e2a1da6f/out/libparking_lot_core-3801e2f2e2a1da6f.rlib" "/home/runner/work/miri/miri/target/release/build/lock_api/0e2d895d91ddbe1a/out/liblock_api-0e2d895d91ddbe1a.rlib" "/home/runner/work/miri/miri/target/release/build/scopeguard/bf5eec70b487ef5b/out/libscopeguard-bf5eec70b487ef5b.rlib" "/home/runner/work/miri/miri/target/release/build/aes/80fb98a96a210235/out/libaes-80fb98a96a210235.rlib" "/home/runner/work/miri/miri/target/release/build/cpubits/3e8c46ad778f86f7/out/libcpubits-3e8c46ad778f86f7.rlib" "/home/runner/work/miri/miri/target/release/build/cpufeatures/18fe67ba3eaef6bd/out/libcpufeatures-18fe67ba3eaef6bd.rlib" "/home/runner/work/miri/miri/target/release/build/cipher/d15b62a10cc2ec99/out/libcipher-d15b62a10cc2ec99.rlib" "/home/runner/work/miri/miri/target/release/build/inout/525f5e448b9de16b/out/libinout-525f5e448b9de16b.rlib" "/home/runner/work/miri/miri/target/release/build/crypto-common/04c6bcb29cdd3fa4/out/libcrypto_common-04c6bcb29cdd3fa4.rlib" "/home/runner/work/miri/miri/target/release/build/hybrid-array/aa6ffe623e7bfea9/out/libhybrid_array-aa6ffe623e7bfea9.rlib" "/home/runner/work/miri/miri/target/release/build/typenum/2e73db423490f594/out/libtypenum-2e73db423490f594.rlib" "/home/runner/work/miri/miri/target/release/build/chrono-tz/0adc3b970614e15c/out/libchrono_tz-0adc3b970614e15c.rlib" "/home/runner/work/miri/miri/target/release/build/phf/e5204e816703d512/out/libphf-e5204e816703d512.rlib" "/home/runner/work/miri/miri/target/release/build/phf_shared/36f0f8f974163d11/out/libphf_shared-36f0f8f974163d11.rlib" "/home/runner/work/miri/miri/target/release/build/siphasher/56a29901c40cbc8c/out/libsiphasher-56a29901c40cbc8c.rlib" "/home/runner/work/miri/miri/target/release/build/chrono/6e4e2a3c91cb6e07/out/libchrono-6e4e2a3c91cb6e07.rlib" "/home/runner/work/miri/miri/target/release/build/num-traits/b17e54b36344b4a2/out/libnum_traits-b17e54b36344b4a2.rlib" "/home/runner/work/miri/miri/target/release/build/bitflags/8d0761067f7c2f2f/out/libbitflags-8d0761067f7c2f2f.rlib" "/home/runner/work/miri/miri/target/release/build/serde/d2436d35c16be608/out/libserde-d2436d35c16be608.rlib" "/home/runner/work/miri/miri/target/release/build/serde_core/603537d6fd6fed8c/out/libserde_core-603537d6fd6fed8c.rlib" "/home/runner/work/miri/miri/target/release/build/libffi/a2e24ae477df3b54/out/liblibffi-a2e24ae477df3b54.rlib" "/home/runner/work/miri/miri/target/release/build/libffi-sys/d461abdd542dfb39/out/liblibffi_sys-d461abdd542dfb39.rlib" "/home/runner/work/miri/miri/target/release/build/mio/58c9866d47f565e1/out/libmio-58c9866d47f565e1.rlib" "/home/runner/work/miri/miri/target/release/build/log/6311f34877871a03/out/liblog-6311f34877871a03.rlib" "/home/runner/work/miri/miri/target/release/build/smallvec/40211a3a9b111236/out/libsmallvec-40211a3a9b111236.rlib" "/home/runner/work/miri/miri/target/release/build/rand/75fdd173eed4421c/out/librand-75fdd173eed4421c.rlib" "/home/runner/work/miri/miri/target/release/build/getrandom/c4f2a791e3f9743c/out/libgetrandom-c4f2a791e3f9743c.rlib" "/home/runner/work/miri/miri/target/release/build/libc/d9926cdbd3f01bba/out/liblibc-d9926cdbd3f01bba.rlib" "/home/runner/work/miri/miri/target/release/build/chacha20/9ea74cbee8151503/out/libchacha20-9ea74cbee8151503.rlib" "/home/runner/work/miri/miri/target/release/build/cfg-if/ddb446835519044b/out/libcfg_if-ddb446835519044b.rlib" "/home/runner/work/miri/miri/target/release/build/rand_core/ad55995e6c234549/out/librand_core-ad55995e6c234549.rlib" "-Wl,-Bdynamic" "<sysroot>/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_driver-e5626671c701e88f.so" "-Wl,-Bstatic" "<sysroot>/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcompiler_builtins-*.rlib" "-Wl,-Bdynamic" "-ldl" "-lLLVM-23-rust-1.100.0-nightly" "-ldl" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-L" "/home/runner/work/miri/miri/target/release/build/miri/cd7c7136867df99d/out/rustcCgh8cr/raw-dylibs" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/home/runner/work/miri/miri/target/release/build/capstone-sys/c9d4335146bfa0df/out" "-L" "/home/runner/work/miri/miri/target/release/build/libffi-sys/a3eb5cb25babb541/out/libffi-root/lib" "-L" "/home/runner/work/miri/miri/target/release/build/libffi-sys/a3eb5cb25babb541/out/libffi-root/lib32" "-L" "/home/runner/work/miri/miri/target/release/build/libffi-sys/a3eb5cb25babb541/out/libffi-root/lib64" "-L" "<sysroot>/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-o" "/home/runner/work/miri/miri/target/release/build/miri/cd7c7136867df99d/out/miri" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-Wl,--strip-debug" "-nodefaultlibs" "-Wl,-rpath,<sysroot>/lib/rustlib/aarch64-unknown-linux-gnu/lib"
= note: some arguments are omitted. use `--verbose` to show all linker arguments
= note: /usr/bin/ld: /home/runner/.rustup/toolchains/miri/lib/rustlib/aarch64-unknown-linux-gnu/lib/libtikv_jemalloc_sys-94b57e83a66832ed.rlib: error adding symbols: file format not recognized
collect2: error: ld returned 1 exit status
```
Fix a couple of links in AVR target documentation

- Update a link to MCU list in the code and make it an actual link
- Make avr-tester link point to the crate page (which is more expected and informative) instead of a repository (which has also moved)
rustc-dev-guide subtree update

Subtree update of `rustc-dev-guide` to 5613bfe.

Created using https://github.com/rust-lang/josh-sync.

r? @ghost
…uwer

Rollup of 5 pull requests

Successful merges:

 - rust-lang/rust#161218 (Revert "Rollup merge of rust-lang/rust#161006 - GuillaumeGomez:gcc-binutils, r=Kobzol")
 - rust-lang/rust#160526 (Make const eval return normalized ty)
 - rust-lang/rust#160460 (Fix a couple of links in AVR target documentation)
 - rust-lang/rust#161333 (compiler: Account for default_sanitizers when comparing target modifiers)
 - rust-lang/rust#161343 (rustc-dev-guide subtree update)
Optimize Clippy with PGO



After rustdoc and Cargo, this seemed like an obvious target for PGO.

Perf results: https://perf.rust-lang.org/compare.html?start=390279b302ca98ae270f434100ae3730531d1246&end=caf67342a544d6eab7a40ebf0d02e802f62008a4&stat=instructions:u

- [Quick try build that doesn't optimize Clippy](rust-lang/rust#159642 (comment))
- [Full try build that optimizes Clippy](rust-lang/rust#159642 (comment))
…nn,kobzol

Enable `-Znext-solver` on nightly by default



Implementation of rust-lang/compiler-team#1014 cc rust-lang/blog.rust-lang.org#1896 rust-lang/rust#160895

This enables `-Znext-solver=globally` by default in nightly, but keeps `-Znext-solver=coherence` for most tests.
Fix ordering for `default impl` check in the new solver

The second commit of rust-lang/rust#160605 moved the `default impl` check later, for better performance, which introduced a regression. This commit moves the check a little earlier, so it is after the `args_may_unify` call (thus retaining the perf benefit) but before the `probe_trait_candidate` (which has side-effects).

The check is now duplicated in three `GoalKind::consider_impl_candidate` methods, which is unfortunate, but it fits in with the existing duplicated code in those methods. And it means another copy of the check (in `try_assemble_bounds_via_registered_opaques`) can be removed.

Fixes rust-lang/rust#160994.

r? @lcnr
add a cache to the `WfPredicates` visitor





Part of speeding up compiling `ReShell` with `-Znext-solver`, see rust-lang/trait-system-refactor-initiative#272 and [#t-types/trait-system-refactor > more &#96;reshell&#96; slowness](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/more.20.60reshell.60.20slowness/with/616484452).

The PR changes the `WfPredicates` visitor to only collect new bounds for unique types. That is, if we have a type like:

```
type T0 = Map<Then<Whitespace, Whitespace>>
type T1 = Map<Then<T0, T0>>
type T2 = Map<Then<T1, T1>>
...
type T_N = Map<Then<T_N-1, T_N-1>>
```

etc., the visitor used to end up collecting one WF obligation for each path from `T_N` to its `Whitespace` leaves, even though WF of a type (I believe) doesn't depend on the path the visitor took to get there, which allows us to deduplicate by Ty. Not deduplicating caused us to go O(2^N) here.

next-solver is still about ~5x slower than the old solver on the third reproducer due to some other hidden quadratics, and fixing that seems to be more involved, but I think this PR will still be ✨ An Improvement.

r? lcnr
Error on projection of dyn noncompat type in old trait solver

Trying to fix rust-lang/trait-system-refactor-initiative#269

I am not sure that the check is placed into the right place in the code.

r? lcnr
Add `Default` implementation for `std::sync::Once`
resolver diagnostics: don't swallow labels and point out  similar items as a note, not a label

This was also swallowing labels from `diagnostic:on_unknown`; a typo suggestion would override it.
Improve the ABI between the panic runtime and libstd

* Use the Rust ABI rather than C ABI
* Mark some extern functions as safe
* Move `PanicPayload` from libcore to liballoc and directly reference `Box<dyn Any>` instead of `*mut dyn Any`
* Avoid an unnecessary allocation with panic=abort

Follow up to rust-lang/rust#160440
Add safety comments in alloc::Wtf8

This PR follow up rust-lang/rust#160824 and add some safety section for unsafe APIs. This PR focus on Wtf8 in alloc and fix every `Untriged` mentioned in rust-lang/rust#160824.

Before this PR, rust-lang/rust#161271 had add some safety sections for Wtf8 in core.

I'm looking forward to your review and give me any feedback to improve this PR.
Add some `rustc_type_ir` comments

This PR adds a few comments to `rustc_type_ir`, some of its key components, and `SolverDelegate`. These are the most important and common traits one encounters and some docs will be helpful. Most of it is coming from the prose in https://rustc-dev-guide.rust-lang.org/solve/sharing-crates-with-rust-analyzer.html
Remove leftover immediate creation

`from_immediate` calls left over from refactor d3d3485dd4953e0ed27ec2239ef7baef4e9dc45d can create invalid LLVM IR
…=Mark-Simulacrum

Add Arc/Rc::strong_count_from_raw

Tracking issue: rust-lang/rust#157021
Accepted ACP: rust-lang/libs-team#792

Adds `strong_count_from_raw` to `Arc` and `Rc`: read the strong count directly from a raw pointer, without reconstructing the smart pointer. The existing workaround is `ManuallyDrop::new(Arc::from_raw(ptr))` + `strong_count`, which takes ownership of a reference the caller doesn't own and could cause a double free if not using it properly, the detailed motivation of this in the ACP.

This PR implements strong count only, libs-api deferred weak count until there's a concrete use case.

The body reads the counter by walking back `data_offset` the way `from_raw_in` does, instead of materializing a temporary `Arc`/`Rc`, the call can't accidentally take ownership, and the `Relaxed` load matches `strong_count`. Lives next to `increment_strong_count`/`decrement_strong_count`.

Safety doc: pointer to the value of a live allocation with valid metadata (feeds `data_offset`),  such as pointer returned by `into_raw`, `into_raw_with_allocator`, `as_ptr`.  `T` aligned like that value, strong count ≥ 1 for the duration of the call.
JonathanBrouwer and others added 12 commits August 22, 2026 10:48
Update documentation for `-Zdump-dep-graph`

The supposed output path was incorrect. Using `-Zdump-dep-graph` does NOT emit to `/tmp/dep_graph.gv`, but to 2 files, one being `dep_graph.txt` and the other `dep_graph.dot` in the current directory

r? @jackh726 :: Because kinda related to Incremental Systems Rethought.
Remove fields from TypeKind: Bool, Char, Float and Int

Tracking issue rust-lang/rust#146922

r? @oli-obk

Part of [Refactoring to many methods](https://rust-lang.zulipchat.com/#narrow/channel/572285-goals.2Freflection/topic/Refactoring.20to.20many.20methods/with/592226560) reflection subgoal. See that for the context.
bootstrap: (offload) be stricter about selected compiler and paths

Disclaimer: I used an llm to implement the fixes, since I had more than enough fun with cmake in the past.
I confirm that on a high-level these are the right fixes as far as I can tell, and I reviewed/refactored it.

@sgasho and @Sa4dUs can you two please confirm that it doesn't break the build for you?

Setup:
I started building rustc on a server where cc was pointing to gcc 9, which is too old to build our llvm submodule.
I managed to have gcc point to a newer gcc 13.
I had to set all the cc/cxx etc. in bootstrap.toml to the path to our gcc 13, as it would otherwise pick the gcc 9.
I also build myself clang-24 in a separate folder.

There are unfortunately enough servers out there that default to ancient gcc's, so I think it's worth handling that and make offload bootstrap a bit stricter.

Changes:
Opennmp/Offload currently requires clang since they generate bitcode during bootstrap. Any older (or newer?) clang and especially gcc are unable to do so. We'll drop the bitcode generation soon, but add libc-for-gpu in a follow-up pr, which has effectively the same requirement, so it's worth fixing. We now derive the path to clang from either the explicit clang_dir which a user can pass if they have a pre-built clang, or (preferably) our submodule clang, if we build it ourselves.

I first had an issue with bootstrap building `RustOffload-24`, since cmake found the external llvm-24 instead of our submodule with llvm-23, so that was obviously incompatible. I changed it to force the usage of our LLVM submodule.

I also added code to make clang use the same `libstdc++` which we used when building our llvm submodule (so in my case, the one from gcc-13). Without the code, it picks the `libstdc++` from the (much older) system cc (9.4), which is incompatible and runs into glibcxx_assert.

I _think_ this should be a strict improvement, and it fixes the 3 bugs I ran into.

r? kobzol
…rs-in-fibers, r=ChrisDenton

Avoid arming the Windows TLS destructor guard in fibers

After rust-lang/rust#157645, we use FLS to trigger destructors for thread locals.

In bytecodealliance/wasmtime#14184, it turned out that there's an edge case we didn't cover: if `thread_local/guard/windows.rs::enable` is called from a fiber and later, in a different fiber: (1) the fiber is converted back to a thread and (2) the thread deletes the original fiber, we incorrectly triggers the FLS destructors prematurely.

The fix is simple - avoid arming the FLS slot (setting it to 1) if the calling thread is a fiber.

The issue happened on mingw because it does have target thread local. Tested locally by forcing `registered = false` and checked that the new test fails without the fix.

r? @ChrisDenton
… r=folkertdev

Use bitset for locals_with_use_data

There seems to be very little reason to use Vec of bools, the whole map allocates space for every element anyway.

Not sure how is impactful this is, I noticed it randomly in the code, but this seems like cleaner way to do it (and more common in the compiler codebase)
Warn about running ui-fulldeps tests in stage 1

Mentioned [here](rust-lang/rust#136939 (comment)).

r? jieyouxu
…uwer

Rollup of 19 pull requests

Successful merges:

 - rust-lang/rust#151061 (Build rustc and codegen backends with -Zembed-metadata=no)
 - rust-lang/rust#154992 (Error on projection of dyn noncompat type in old trait solver)
 - rust-lang/rust#157949 (Allow self in const generics)
 - rust-lang/rust#158588 (trait_selection: fix assumptions-on-binders diagnostics)
 - rust-lang/rust#159954 (core: implement float conversion methods)
 - rust-lang/rust#160136 (Add `Default` implementation for `std::sync::Once`)
 - rust-lang/rust#160835 (resolver diagnostics: don't swallow labels and point out  similar items as a note, not a label)
 - rust-lang/rust#161048 (Improve the ABI between the panic runtime and libstd)
 - rust-lang/rust#161292 (Add safety comments in alloc::Wtf8)
 - rust-lang/rust#161444 (Add some `rustc_type_ir` comments)
 - rust-lang/rust#161465 (Remove leftover immediate creation)
 - rust-lang/rust#159098 (Add Arc/Rc::strong_count_from_raw)
 - rust-lang/rust#159282 (Update documentation for `-Zdump-dep-graph`)
 - rust-lang/rust#161401 (Remove fields from TypeKind: Bool, Char, Float and Int)
 - rust-lang/rust#161431 (bootstrap: (offload) be stricter about selected compiler and paths)
 - rust-lang/rust#161451 (Avoid arming the Windows TLS destructor guard in fibers)
 - rust-lang/rust#161463 (Add myself to mailmap)
 - rust-lang/rust#161476 (Use bitset for locals_with_use_data)
 - rust-lang/rust#161483 (Warn about running ui-fulldeps tests in stage 1)

Failed merges:

 - rust-lang/rust#161443 (add internal DSL for testing binders)
Optimize `DeepRejectCtxt`



Details in individual commits.

r? @jdonszelmann
…oxyUwU

Reject non-constructor self types in const-arg tuple-call lowering



Turning on `min_generic_const_args` makes `tracing` stop compiling. Its logging macros expand a field name to something like `FieldName<{ FieldName::len(stringify!(field)) }>`, and under mgca a braced call in const-arg position gets lowered as a tuple constructor. So lowering tries to resolve the bare self type `FieldName` (written without its `const N`), which kicks off an `E0107 "missing generics"` cascade pointing deep into macro code. But `FieldName::len(..)` is just an associated fn, not a constructor, so lowering it like a `TupleCall` was wrong in the first place. See rust-lang/rust#157152.

Only an enum can host a tuple-variant ctor, so for any other self type that can't (struct, union, primitive, foreign type) the call has to be an assoc fn and needs wrapping in `const { ... }`. We catch those from the self type's resolution before lowering it and emit the existing "complex const arguments must be placed inside of a `const` block" error, which is the message you'd want anyway. Enums, aliases, `Self` and type params get left alone since they might resolve to an enum. tbh the bare generic *enum* case (`Option::Some(0)`) still E0107s, and imo that's better as a follow-up since catching it needs the variant type before lowering. Tests cover struct/union/primitive/foreign plus the wrapped forms that compile, and I checked it against the real `tracing` 0.1.44 crate too. 

_fwiw just the code changes and tests were implemented with AI help and I verified/reproduced/tested everything locally before sending to remote._
This updates the rust-version file to da5114692c9ebe46b869488c5f34f92eb10b98c1.
@rustbot

rustbot commented Aug 24, 2026

Copy link
Copy Markdown
Collaborator

Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using r? rustc-dev-guide or r? <username>.

@rustbot rustbot added the S-waiting-on-review Status: this PR is waiting for a reviewer to verify its content label Aug 24, 2026
@tshepang
tshepang merged commit 3bc7a2d into main Aug 24, 2026
1 check passed
@rustbot rustbot removed the S-waiting-on-review Status: this PR is waiting for a reviewer to verify its content label Aug 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants