Rollup of 5 pull requests#159579
Merged
Merged
Conversation
- Boolean target modifiers are now mentioned without a trailing `=` in the messages. - Wording improved for unset target modifiers.
…and NVPTX For AVR, AMDGCN, and NVPTX, crates built with different target CPU values are not generally link-compatible. Add a `requires_consistent_cpu` flag to the target spec and enable it for these targets. When the flag is set, treat `-Ctarget-cpu` as a target modifier and require all linked crates to agree on its value. Reject `-Ctarget-cpu=native` before codegen for targets that set `requires_consistent_cpu` to true. Also do not include `native` in the printed `target-cpus` list for such targets. Add tests covering: - which built-in targets set `requires-consistent-cpu` - cross-crate behavior with and without `requires-consistent-cpu` - that an omitted `-Ctarget-cpu` compares equal to an explicitly specified default CPU - rejection and printing behavior for `native` - precedence of repeated `-Ctarget-cpu` flags in metadata comparison and LLVM IR
…k-Simulacrum
Always generate private and hidden items in JSON docs of the stdlib
This data is needed for downstream tools, e.g. cargo-semver-checks, to analyse the whole stdlib.
For the HTML output it is configurable using `build.library-docs-private-items`, but to avoid adding a separate config for just the JSON format, I think that we can just enable it unconditionally.
An alternative would be to change the flag from a bool to something like
```rust
enum StdDocsPrivateItems {
No,
Yes,
Html,
Json
}
```
…am_epoch, r=Mark-Simulacrum Update rustc crate crossbeam-epoch to 0.9.20 See https://rustsec.org/advisories/RUSTSEC-2026-0204.html and crossbeam-rs/crossbeam#1276
…orn3 Convert `-Ctarget-cpu` into a target-modifier for AVR, AMDGCN and NVPTX Crates built for AVR, AMDGCN and NVPTX that specify different values for `-Ctarget-cpu` cannot be soundly linked together. This PR attempts to make `rustc` ensure that no crates with disagreeing values for `-Ctarget-cpu` are linked together. This is achieved by converting `-Ctarget-cpu` into a target-modifier depending on `--target`. To do this, the consistency check for `-Ctarget-cpu` considers mismatching values as inconsistent only for targets for which the new flag `requires_consistent_cpu` is set in their target spec. **Why should `-Ctarget-cpu` be a target-modifier for `nvptx`?** <details><summary>PTX is a single-module contract</summary> <p> PTX requires a binary to start with .version (`ptx$$`) then .target (`sm_$$`). If the ptx contains instructions that are not supported by either .version or .target, the binary is ill-formed and will be rejected by ptxas. The concept of features that can be mixed and matched in a binary does not exist for nvptx and is therefore not supported by LLVM. </p> </details> <details><summary>It prevents the production of bitcode that cannot be codegen'd after linking</summary> <p> A target modifier should prevent configurations that are not composable across crates when those crates are linked together. The most prominent example is when enabling a target feature changes the ABI, making cross-crate calls inherently unsound. In the case of nvptx, ABI mismatch is (at least for now) not the core problem motivating target modifiers. NVIDIA’s documented PTX calling convention has [remained stable since ptx20](https://docs.nvidia.com/cuda/ptx-writers-guide-to-interoperability/index.html#function-calling-sequence). However, in the current state it is possible to produce bitcode that cannot be codegen'd after linking, because some operations are only lowerable for sufficiently new SM/PTX levels. In the best case this results in an LLVM error during the final llc step, but this is not something we should rely on for correctness. nvptx has a special compilation pipeline where instead of linking the final PTX object, instead LLVM bitcode is linked. The resulting artifact is then compiled in one invocation. Now consider crate A which is independently compiled into bitcode with the following rustc arguments: ```Rust //@ compile-flags: --target nvptx64-nvidia-cuda -C target-cpu=sm_70 --crate-type=rlib #[cfg(target_feature = "sm_70")] fn foo() { // cannot be lowered to ptx before "sm_70: so currently produces an LLVM error } #[cfg(not(target_feature = "sm_70"))] fn foo() { // can be lowered to ptx before "sm_70" } pub fn bar() { foo() } ``` Crate A is a dependency of crate B. In the *rustc* invocation of crate B 1. crate B is compiled into bitcode, too 2. both bitcode artifacts are bitcode-linked by *llvm-link* 3. the resulting bitcode artifact is compiled by *llc -mcpu=sm_60* This should now ideally create an LLVM error, because the linked bitcode contains code paths that were selected under `sm_70` assumptions but the final NVPTX codegen is targeting `sm_60`, where those operations are not lowerable. An LLVM error here is better than silent miscompilation, but it’s not a promise we should rely on. A real example where this could happen is the lowering of atomic loads and stores with non-relaxed orderings, which is known to depend on the selected SM level. </p> </details> **Why should `-Ctarget-cpu` be a target-modifier for `amdgcn` and `avr`?** - In case of AVR the target-cpu defines the ISA, which is encoded in the ELF header flags, amdgcn also encodes the cpu directly into those flags - To not rely on *lld* which currently prevents it for both by looking at those flags [AVR](https://github.com/llvm/llvm-project/blob/597ffbe09d5f774f861ee55e50022bf84d7f98e2/lld/test/ELF/avr-flags.s) and [amdgcn](https://github.com/llvm/llvm-project/blob/597ffbe09d5f774f861ee55e50022bf84d7f98e2/lld/test/ELF/amdgpu-elf-flags-err.s) Previous discussions about the topic can be found [here](rust-lang#131799 (comment)) and [here](rust-lang#141468). I also created a [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Making.20-Ctarget-cpu.20a.20target-modifier.20on.20NVPTX/with/566622679). I am unsure if a MCP is needed before proceeding. If you think so please let me know. Creating *target-modifiers* for NVPTX *target-features* is to be done in a follow-up. cc @kjetilkjeka as target maintainer for NVPTX cc @Flakebi as target maintainer for amdgcn cc @Patryk27 as target maintainer for AVR cc @RalfJung you were very involved in the discussions so far Target modifier tracking issue: rust-lang#136966
…ark-Simulacrum restrict const-eval-related 'content' triggers to library/ folder Cc @rust-lang/wg-const-eval The 2nd commit is a drive-by fix.
fix ICE in opsem inhabitedness check I feel like maybe rust-lang#159560 should be avoided by not even trying to evaluate this constant... but anyway it makes sense to make this query tolerant to `ty::Error` IMO. The error message we emit still makes no sense, but that's a separate issue and better than ICEing. Fixes rust-lang#159560 r? @oli-obk
rustbot
added
A-LLVM
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 19, 2026
…uwer Rollup of 5 pull requests Successful merges: - #159188 (Always generate private and hidden items in JSON docs of the stdlib) - #159567 (Update rustc crate crossbeam-epoch to 0.9.20) - #150732 (Convert `-Ctarget-cpu` into a target-modifier for AVR, AMDGCN and NVPTX ) - #159549 (restrict const-eval-related 'content' triggers to library/ folder) - #159570 (fix ICE in opsem inhabitedness check)
rust-bors
Bot
added
S-waiting-on-review
Contributor
Member
|
The only meaningful diagnostics are @bors retry |
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors
Bot
added
merged-by-bors
Contributor
This was referenced Jul 20, 2026
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: 9f36de775b In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jul 20, 2026
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 9f36de7 (parent) -> 730a6b5 (this PR) Test differencesShow 31 test diffsStage 1
Stage 2
Additionally, 6 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 730a6b5dce9477b819de0ba79d6e7945e1248e3d --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Collaborator
|
Finished benchmarking commit (730a6b5): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)This perf run didn't have relevant results for this metric. CyclesResults (secondary -2.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 484.26s -> 485.867s (0.33%) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
-Ctarget-cpuinto a target-modifier for AVR, AMDGCN and NVPTX #150732 (Convert-Ctarget-cpuinto a target-modifier for AVR, AMDGCN and NVPTX )r? @ghost
Create a similar rollup