Rollup of 6 pull requests#158639
Merged
Merged
Conversation
To emphasize that just because you see a `Scalar(I32)` that doesn't really tell you anything about the alignment it has -- one should be looking at the type (well, the place) for that. No actual layout or behaviour changes in *this* PR.
Co-authored-by: Ralf Jung <post@ralfj.de>
- aarch64-unknown-nto-qnx800 becomes simply aarch64-unknown-qnx - x86_64-pc-nto-qnx800 becomes simply x86_64-pc-qnx - references to QNX OS and QNX Neutrino RTOS are replaced with QNX SDP for uniformity - various nto_qnx modules are named to qnx_sdp to match the above The new target names are more consistent with those used by the QNX SDP 8.0 toolchain, and reflect a level on ongoing API stability similar to that for macOS and Linux (which simply have minimum supported versions record for their targets). Once the compiler knows about the new target names, libc and backtrace can be updated to match, and then building libstd for the new targets can be fixed. With these changes I can run: ```console $ ./x build library/std --stage 2 --target x86_64-pc-nto-qnx710,aarch64-unknown-nto-qnx710,x86_64-pc-nto-qnx710_iosock,aarch64-unknown-nto-qnx710_iosock,aarch64-unknown-nto-qnx700 $ ./x build library/core --stage 1 --target x86_64-pc-qnx,aarch64-unknown-qnx ```
The name of the OS had changed, so the tests needed updating
- Now explains what SDP is - Moves sections into a more useful order - Re-wrap long blocks of text
Just in case we were deliberately pairing up these OSes
No code changes required, and this cleans up recursive dependencies too.
…without-depth-increase, r=lcnr Do not increase depth when evaluating nested goals of `NormalizesTo` cc rust-lang#156619 (comment) ~~Only the last commit is relevant since this is based on rust-lang#156619~~ r? lcnr
…rkingjubilee QNX target renaming This PR renames two QNX targets: - `aarch64-unknown-nto-qnx800` becomes simply `aarch64-unknown-qnx` - `x86_64-pc-nto-qnx800` becomes simply `x86_64-pc-qnx` In addition: - references to *QNX OS* and *QNX Neutrino RTOS* are replaced with *QNX SDP* for uniformity - the `spec::base::nto_qnx` module is renamed to `base::spec::qnx_sdp` to match the above - the `target_os` of the QNX SDP 8.0 targets is changed to `qnx` to match the target name - a *lot* of code is then touched to handle `any(target_os = "nto", target_os = "qnx")` I think it's worth noting that *QNX Software Development Platform* is the *build environment* that you download and install, and you can use it to create a custom *run-time environment*. In SDP 7.x the run-time environment was based on *QNX Neutrino 7.x*, but in SDP 8.0 the run-time environment is based on *QNX OS 8.0*. I think it was weird to users to see the two different run-time environments in the docs, and referring to the build environment just seems to make more sense anyway because that's what users install, it's where the headers live, and ultimately it's what the toolchain will care about. The new target names match those reported by `clang` running *on* the [self-hosted *QNX Developer Desktop*](https://www.qnx.com/developers/docs/qnxeverywhere/com.qnx.doc.qdd/topic/about.html). ```console $ clang --version QNX clang version 21.1.3 Target: x86_64-pc-qnx Thread model: posix InstalledDir: /usr/bin ``` Once the compiler knows about the new target names, `libc`, `backtrace` and `cc-rs` can be updated to match, and then building `libstd` for the new targets can be fixed. This rename will cause a bit of churn, but it seemed important to get it changed before anyone tries to finish libstd support for QNX SDP 8.0 (it's currently noted as "in-progress"). It's also Tier 3 so we have fairly broad latitude to do this I think, and aligning with QNX's build of clang just makes sense. With these changes I can run: ```console $ ./x build library/std --stage 2 --target x86_64-pc-nto-qnx710,aarch64-unknown-nto-qnx710,x86_64-pc-nto-qnx710_iosock,aarch64-unknown-nto-qnx710_iosock,aarch64-unknown-nto-qnx700 $ ./x build library/core --stage 1 --target x86_64-pc-qnx,aarch64-unknown-qnx ``` The QNX SDP 7.x targets retain their old names, and their `target_os = "nto", target_env = "qnx710"` configuration, to avoid breakage.
signed strict division: just use normal division For some reason, rust-lang#116090 picked an unnecessarily complicated implementation for this. I don't know if there was any specific reason for this;. Cc @rmehri01 @m-ou-se in case someone remembers. This was pointed out on IRLO: https://internals.rust-lang.org/t/why-is-strict-div-implemented-in-terms-of-overflowing-div-for-signed-integers/24387 Let's just use regular division here, which is consistent with what we do for unsigned types.
…obzol,jieyouxu Deduplicate codegen backends in bootstrap config Deduplicate `rust.codegen-backends` and `target.<triple>.codegen-backends` during bootstrap config parsing while preserving first occurrence order. This avoids carrying redundant backend entries into later bootstrap planning. test: ```powershell $env:CARGO_NET_OFFLINE='false'; $env:CARGO_TARGET_DIR='target-codex-test'; $cargo = Join-Path $env:USERPROFILE '.cargo\bin\cargo.exe'; & $cargo test --manifest-path src/bootstrap/Cargo.toml deduplicates_codegen_backends ``` result: ```text running 1 test test core::config::tests::deduplicates_codegen_backends ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 255 filtered out; finished in 0.00s ```
…ingjubilee Rename `align` to `default_align` on `Scalar` and `Primitive` To emphasize that just because you see a `Scalar(I32)` that doesn't really tell you anything about the alignment it has -- one should be looking at the type (well, the place) for that. (The `size` method doesn't really have that problem -- i32 is always 4 bytes, no matter the context -- so is left untouched.) No actual layout or behaviour changes in *this* PR. Just the rename and some comments. r? @workingjubilee
…huss linkchecker: upgrade to `html5ever v0.39` No code changes required, and this cleans up recursive dependencies too.
rustbot
added
A-LLVM
rustbot
added
the
WG-trait-system-refactor
Member
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
added
merged-by-bors
Contributor
This was referenced Jul 1, 2026
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: 17aa77551e In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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 17aa775 (parent) -> 7c5dac9 (this PR) Test differencesShow 2869 test diffsStage 0
Stage 1
Stage 2
Additionally, 2852 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 7c5dac9c7476a30e09a5aa87b4df2c5663fe7734 --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 (7c5dac9): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Our benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (secondary 9.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.6%, secondary 46.2%)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: 486.291s -> 488.078s (0.37%) |
Collaborator
|
A job failed! Check out the build log: (web) (plain enhanced) (plain) Click to see the possible cause of the failure (guessed by this bot) |
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
10 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:
NormalizesTo#157718 (Do not increase depth when evaluating nested goals ofNormalizesTo)aligntodefault_alignonScalarandPrimitive#158542 (Renamealigntodefault_alignonScalarandPrimitive)html5ever v0.39#158636 (linkchecker: upgrade tohtml5ever v0.39)r? @ghost
Create a similar rollup