-
Notifications
You must be signed in to change notification settings - Fork 410
Automatic Rustup #4377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Automatic Rustup #4377
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
Rework `collect_and_apply` to not rely on size hint for optimization I saw that we have quite a few `collect_and_apply` calls for N=3-7 (N=7 corresponding to cumulative 99% of nalgebra's calls). Didn't perf locally, but also this is super low-pri, so let's see what rust-timer says.
…cs, 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.
…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/rust#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/rust#132422, rust-lang/rust#132741, rust-lang/rust#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/rust#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/rust#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/rust#134288 [1]: rust-lang/rust#54341 [2]: rust-lang/rust#128950
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
…kingjubilee add s390x z17 target features tracking issue: rust-lang/rust#130869 earlier target features were added in rust-lang/rust#135630, and rust-lang/rust#135413 (comment) has some extra context on these new features. r? ``@ghost`` cc ``@uweigand``
make `OsString::new` and `PathBuf::new` unstably const Since #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`
…mpiler-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
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/rust#141991
Rollup of 8 pull requests Successful merges: - rust-lang/rust#136687 (Improve the documentation of `Display` and `FromStr`, and their interactions) - rust-lang/rust#137306 (Remove `i128` and `u128` from `improper_ctypes_definitions`) - rust-lang/rust#138699 (build dist for x86_64-pc-solaris and sparcv9-sun-solaris) - rust-lang/rust#141250 (add s390x z17 target features) - rust-lang/rust#141467 (make `OsString::new` and `PathBuf::new` unstably const) - rust-lang/rust#141871 (index: add method for checking range on DenseBitSet) - rust-lang/rust#141888 (Use non-2015 edition paths in tests that do not test for their resolution) - rust-lang/rust#142000 (bootstrap: don't symlink source dir into stage0 sysroot) r? `@ghost` `@rustbot` modify labels: rollup
redesign stage 0 std follow-ups part2 Fixes three bugs: 1. `x check` fails when run on rustdoc without `download-rustc` enabled. (1st commit) 2. `x check` fails when run on the compiler with `download-rustc` enabled. (2nd commit) 3. `x test library` fails with `download-rustc` enabled. (3rd commit) Fixes rust-lang/rust#142018 (case 1) Fixes rust-lang/rust#141983 (case 3)
…ngjubilee x86 (32/64): go back to passing SIMD vectors by-ptr Fixes rust-lang/rust#139029 by partially reverting rust-lang/rust#135408 and going back to passing SIMD vectors by-ptr on x86. Sadly, by-val confuses the LLVM inliner so much that it's not worth it... Also fixes rust-lang/rust#141848 by no longer actually using vector registers with the "Rust" ABI. r? `@tgross35` Cc `@nikic` try-job: `test-various*` try-job: dist-i586-gnu-i586-i686-musl try-job: x86_64-gnu-nopt try-job: `x86_64-msvc*` try-job: `i686-msvc*`
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.
Please close and re-open this PR to trigger CI, then enable auto-merge.