Rollup of 8 pull requests #142003
Merged
Rollup of 8 pull requests #142003
Conversation
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
Rust's 128-bit integers have historically been incompatible with C [1]. However, there have been a number of changes in Rust and LLVM that mean this is no longer the case: * Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment proposed at rust-lang/compiler-team#683, implemented at rust-lang#116672. * LLVM version of the above: resolved in LLVM, including ABI fix. Present in LLVM18 (our minimum supported version). * Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]: Rust's data layouts adjusted at rust-lang#132422, rust-lang#132741, rust-lang#134115. * LLVM version of the above: done in LLVM 20 llvm/llvm-project#102783. * Incorrect return convention of `i128` on Windows: adjusted to match GCC and Clang at rust-lang#134290. At [3], the lang team considered it acceptable to remove `i128` from `improper_ctypes_definitions` if the LLVM version is known to be compatible. Time has elapsed since then and we have dropped support for LLVM versions that do not have the x86 fixes, meaning a per-llvm-version lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes only came in LLVM 20 but since Rust's datalayouts have also been updated to match, we will be using the correct alignment regardless of LLVM version. `repr(i128)` was added to this lint in [4], but is also removed here. Part of the decision is that `i128` should match `__int128` in C on platforms that provide it, which documentation is updated to indicate. We will not guarantee that `i128` matches `_BitInt(128)` since that can be different from `__int128`. Some platforms (usually 32-bit) do not provide `__int128`; if any ABIs are extended in the future to define it, we will need to make sure that our ABI matches. Closes: rust-lang#134288 Closes: rust-lang#128950 [1]: rust-lang#54341 [2]: rust-lang#128950 [3]: rust-lang/lang-team#255 (comment) [4]: rust-lang#138282
…tion This allows for testing these tests on editions other than 2015
…actions In particular: - `Display` is not necessarily lossless - The output of `Display` might not be parseable by `FromStr`, and might not produce the same value if it is. - Calling `.parse()` on the output of `Display` is usually a mistake unless a type's documented output and input formats match. - The input formats accepted by `FromStr` depend on the type.
- Drop the phrasing "usually a mistake". - Mention that `Display` may not be lossless. - Drop a misplaced parenthetical about round-tripping that didn't fit the paragraph it was in.
- Drop "usually a mistake" - Add phrasing from `FromStr` about round-tripping, and about how the inability to round-trip may surprise users.
In StdLink::run we subsequently recursively copy the initial sysroot lib directory into the stage0-sysroot lib directory. If the initial sysroot is a toolchain that includes the `rust-src` component (in lib/rustlib/src/rust), if we add this symlink, that recursive copy will overwrite the repo sources with the toolchain's sources.
…romstr-docs, r=Amanieu Improve the documentation of `Display` and `FromStr`, and their interactions In particular: - `Display` is not necessarily lossless - The output of `Display` might not be parseable by `FromStr`, and might not produce the same value if it is. - Calling `.parse()` on the output of `Display` is usually a mistake unless a type's documented output and input formats match. - The input formats accepted by `FromStr` depend on the type. This documentation adds no API surface area and makes no guarantees about stability. To the best of my knowledge, everything it says is already established to be true. As such, I don't think it needs an FCP.
…-ctypes, r=traviscross,workingjubilee Remove `i128` and `u128` from `improper_ctypes_definitions` Rust's 128-bit integers have historically been incompatible with C [1]. However, there have been a number of changes in Rust and LLVM that mean this is no longer the case: * Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment proposed at rust-lang/compiler-team#683, implemented at rust-lang#116672. * LLVM version of the above: resolved in LLVM, including ABI fix. Present in LLVM18 (our minimum supported version). * Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]: Rust's data layouts adjusted at rust-lang#132422, rust-lang#132741, rust-lang#134115. * LLVM version of the above: done in LLVM 20 llvm/llvm-project#102783. * Incorrect return convention of `i128` on Windows: adjusted to match GCC and Clang at rust-lang#134290. At rust-lang/lang-team#255 (comment), the lang team considered it acceptable to remove `i128` from `improper_ctypes_definitions` if the LLVM version is known to be compatible. Time has elapsed since then and we have dropped support for LLVM versions that do not have the x86 fixes, meaning a per-llvm-version lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes only came in LLVM 20 but since Rust's datalayouts have also been updated to match, we will be using the correct alignment regardless of LLVM version. `repr(i128)` was added to this lint in rust-lang#138282, but is also removed here. Part of the decision is that `i128` should match `__int128` in C on platforms that provide it, which documentation is updated to indicate. We will not guarantee that `i128` matches `_BitInt(128)` since that can be different from `__int128`. Some platforms (usually 32-bit) do not provide `__int128`; if any ABIs are extended in the future to define it, we will need to make sure that our ABI matches. Closes: rust-lang#134288 [1]: rust-lang#54341 [2]: rust-lang#128950
…oieni build dist for x86_64-pc-solaris and sparcv9-sun-solaris try-job: dist-sparcv9-solaris try-job: dist-x86_64-solaris try-job: dist-various-2 try-job: dist-x86_64-illumos
…es, r=workingjubilee add s390x z17 target features tracking issue: rust-lang#130869 earlier target features were added in rust-lang#135630, and rust-lang#135413 (comment) has some extra context on these new features. r? ``@ghost`` cc ``@uweigand``
…=Amanieu make `OsString::new` and `PathBuf::new` unstably const Since rust-lang#129041, `String::into_bytes` is `const`, which allows making `OsString::new` and `PathBuf::new` unstably const now. Not sure what the exact process for this is; does it need an ACP?
index: add method for checking range on DenseBitSet Micro-optimisation that Miri benefits from with the new isolated allocator for native-libs mode. Also possibly just a useful method to have on `DenseBitSet`
…015, r=compiler-errors Use non-2015 edition paths in tests that do not test for their resolution This allows for testing these tests on editions other than 2015
…ur-ozkan bootstrap: don't symlink source dir into stage0 sysroot In StdLink::run we subsequently recursively copy the initial sysroot lib directory into the stage0-sysroot lib directory. If the initial sysroot is a toolchain that includes the `rust-src` component (in lib/rustlib/src/rust), if we add this symlink, that recursive copy will overwrite the repo sources with the toolchain's sources. Fixes rust-lang#141991
rustbot
added
A-LLVM
|
@bors r+ rollup=never p=5 |
bors
removed
the
S-waiting-on-review
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: d9a7393638 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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 d9a7393 (parent) -> 61413ae (this PR) Test differencesShow 293 test diffsStage 1
Additionally, 292 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 61413aea937d9663d01b62902535f8d4ec85cc95 --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 |
|
Finished benchmarking commit (61413ae): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 1.8%, secondary -1.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 748.459s -> 749.479s (0.14%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
DisplayandFromStr, and their interactions #136687 (Improve the documentation ofDisplayandFromStr, and their interactions)i128andu128fromimproper_ctypes_definitions#137306 (Removei128andu128fromimproper_ctypes_definitions)OsString::newandPathBuf::newunstably const #141467 (makeOsString::newandPathBuf::newunstably const)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup