Sync from rust 2026/08/21 - #959
Conversation
This will allow introducing a separate incr comp session dir for the post LTO artifacts in the future. In addition it statically encodes the lifetime of the incr comp session rather than requiring an enum behind a mutex stored in the Session.
Split IncrCompSession out of Session This will allow introducing a separate incr comp session dir for the post LTO artifacts in the future. In addition it statically encodes the lifetime of the incr comp session rather than requiring an enum behind a mutex stored in the Session. Based on rust-lang/rust#159000 Part of rust-lang/compiler-team#908
…rcote refactor handling of target features in Session `Session` currently contains two lists of target features: `target_features`, which is also exposed in `cfg`, and `unstable_target_features`, which is used internally to communicate between various parts of the compiler which target features are *actually* available, including some that we don't have plans to put in `cfg`, namely "forbidden" target features. The `unstable_target_features` list is *not* equivalent to what nightly code sees in `cfg(target_features)` as the latter excludes "forbidden" target features. Both lists are computed by `fn cfg_target_features` even though one of them is never used for `cfg`. It's all kind of messy. This PR refactors that: `fn cfg_target_features` is replaced by `fn internal_target_features` which computes all enabled Rust target features (including "forbidden" ones -- which are really more like "internal-only" ones so the 2nd commit renames them). We then compute `cfg(target_features)` from that. The session only stores one list, `internal_target_features`, which corresponds to the previous `unstable_target_features`. To simplify computing `internal_target_features` I also refactored `parse_rust_feature_list` to better distinguish actual Rust target features from unknown target features that we are just grandfathering in. I also made `implied_target_features` not rebuild the same hash map over and over again. And I got rid of a bunch of silly temporary vectors and iterations over all Rust target features.
- Upgrade from `getrandom v0.4.2` to `v0.4.3` to drop its `wasip2` and `wasip3` dependencies and many transitives. - Upgrade from `gimli v0.33` to `v0.34` as a direct dependency and through a `thorin-dwp` upgrade. - Upgrade from `object v0.37` and `v0.38` to `v0.39` as a direct dependency and via `ar_archive_writer` and `thorin-dwp` upgrades. - Upgrade `libloading` and `wasmparser` to match other dependencies. This also consolidates from `hashbrown v0.15`, `v0.16`, and `v0.17` to just `v0.17.1`, which is the same that `std` currently uses.
atomic volatile: add intrinsics Extend the atomic load/store intrinsics to also support volatile atomic load/store. Tracking issue: rust-lang/rust#158947. Library APIs that use these intrinsics will be added inn a future PR. The GCC and cranelift implementations ignore the volatile flag, not sure how that should be implemented for them.
|
@folkertdev: The CI hit the error you added here. |
|
I don't know so I'd guess not? I just look at the path that showed up in the error messages. |
Do you know how to fix this in compiletest? |
|
Hmm actually looking into it, that change uses let gcc_supported_target_tuples = match default_codegen_backend {
CodegenBackend::Gcc => {
directives::find_gcc_supported_targets(&args.sysroot_base, &args.host)
}
CodegenBackend::Llvm | CodegenBackend::Cranelift => vec![],
};which is documented as /// Directory containing the compiler sysroot.
#[arg(long)]
sysroot_base: Utf8PathBuf,I'm not really sure what to look for here beyond that. What is the path you expect the sysroot to be at? For reference the code currently tries to look at |
We provide our own sysroot at this path: |
|
Hmm, I think the answer is to use @jieyouxu does that sound right? If so, what would be the best way to go about that? During I'm not really sure whether the sysroot rustc reports is sufficient or whether we should still also check the |
7 participants
No description provided.