Upgrade rust to 1.86.0 #17
Closed
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
Rollup of 10 pull requests Successful merges: - #136758 (tests: `-Copt-level=3` instead of `-O` in assembly tests) - #136761 (tests: `-Copt-level=3` instead of `-O` in codegen tests) - #136784 (Nuke `Buffer` abstraction from `librustdoc`, take 2 💣) - #136838 (Check whole `Unsize` predicate for escaping bound vars) - #136848 (add docs and ut for bootstrap util cache) - #136871 (dev-guide: Link to `t-lang` procedures for new features) - #136890 (Change swap_nonoverlapping from lang to library UB) - #136901 (compiler: give `ExternAbi` truly stable `Hash` and `Ord`) - #136907 (compiler: Make middle errors `pub(crate)` and bury the dead code) - #136916 (use cc archiver as default in `cc2ar`) r? `@ghost` `@rustbot` modify labels: rollup
This will be used in Clippy to detect unbuffered calls to `Read::bytes()`.
I'm back from vacation.
This continues two ongoing projects: - Replacing ascii art with real icons that don't look like syntax, are understandable to people who're familiar with desktop computers and smart devices, and aren't ugly. - Using labels and tooltips to clarify these icons, when the limits of popular iconography hit us. In this case, I've added tooltips, because, unfortunately, there's not room for always-visible labels.
Rename rustc_middle::Ty::is_unsafe_ptr to is_raw_ptr The wording unsafe pointer is less common and not mentioned in a lot of places, instead this is usually called a "raw pointer". For the sake of uniformity, we rename this method. This came up during the review of rust-lang/rust#134424. r? `@Noratrieb`
for `range_into_bounds` feature, #136903
Stabilize target_feature_11 # Stabilization report This is an updated version of rust-lang/rust#116114, which is itself a redo of rust-lang/rust#99767. Most of this commit and report were copied from those PRs. Thanks ```@LeSeulArtichaut``` and ```@calebzulawski!``` ## Summary Allows for safe functions to be marked with `#[target_feature]` attributes. Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot *generally* be assigned to safe function pointers, and don't implement the `Fn*` traits. However, calling them from other `#[target_feature]` functions with a superset of features is safe. ```rust // Demonstration function #[target_feature(enable = "avx2")] fn avx2() {} fn foo() { // Calling `avx2` here is unsafe, as we must ensure // that AVX is available first. unsafe { avx2(); } } #[target_feature(enable = "avx2")] fn bar() { // Calling `avx2` here is safe. avx2(); } ``` Moreover, once rust-lang/rust#135504 is merged, they can be converted to safe function pointers in a context in which calling them is safe: ```rust // Demonstration function #[target_feature(enable = "avx2")] fn avx2() {} fn foo() -> fn() { // Converting `avx2` to fn() is a compilation error here. avx2 } #[target_feature(enable = "avx2")] fn bar() -> fn() { // `avx2` coerces to fn() here avx2 } ``` See the section "Closures" below for justification of this behaviour. ## Test cases Tests for this feature can be found in [`tests/ui/target_feature/`](https://github.com/rust-lang/rust/tree/f6cb952dc115fd1311b02b694933e31d8dc8b002/tests/ui/target-feature). ## Edge cases ### Closures * [target-feature 1.1: should closures inherit target-feature annotations? #73631](rust-lang/rust#73631) Closures defined inside functions marked with #[target_feature] inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits. ```rust #[target_feature(enable = "avx2")] fn qux() { let my_closure = || avx2(); // this call to `avx2` is safe let f: fn() = my_closure; } ``` This means that in order to call a function with #[target_feature], you must guarantee that the target-feature is available while the function, any closures defined inside it, as well as any safe function pointers obtained from target-feature functions inside it, execute. This is usually ensured because target features are assumed to never disappear, and: - on any unsafe call to a `#[target_feature]` function, presence of the target feature is guaranteed by the programmer through the safety requirements of the unsafe call. - on any safe call, this is guaranteed recursively by the caller. If you work in an environment where target features can be disabled, it is your responsibility to ensure that no code inside a target feature function (including inside a closure) runs after this (until the feature is enabled again). **Note:** this has an effect on existing code, as nowadays closures do not inherit features from the enclosing function, and thus this strengthens a safety requirement. It was originally proposed in #73631 to solve this by adding a new type of UB: “taking a target feature away from your process after having run code that uses that target feature is UB” . This was motivated by userspace code already assuming in a few places that CPU features never disappear from a program during execution (see i.e. https://github.com/rust-lang/stdarch/blob/2e29bdf90832931ea499755bb4ad7a6b0809295a/crates/std_detect/src/detect/arch/x86.rs); however, concerns were raised in the context of the Linux kernel; thus, we propose to relax that requirement to "causing the set of usable features to be reduced is unsafe; when doing so, the programmer is required to ensure that no closures or safe fn pointers that use removed features are still in scope". * [Fix #[inline(always)] on closures with target feature 1.1 #111836](rust-lang/rust#111836) Closures accept `#[inline(always)]`, even within functions marked with `#[target_feature]`. Since these attributes conflict, `#[inline(always)]` wins out to maintain compatibility. ### ABI concerns * [The extern "C" ABI of SIMD vector types depends on target features #116558](rust-lang/rust#116558) The ABI of some types can change when compiling a function with different target features. This could have introduced unsoundness with target_feature_11, but recent fixes (#133102, #132173) either make those situations invalid or make the ABI no longer dependent on features. Thus, those issues should no longer occur. ### Special functions The `#[target_feature]` attribute is forbidden from a variety of special functions, such as main, current and future lang items (e.g. `#[start]`, `#[panic_handler]`), safe default trait implementations and safe trait methods. This was not disallowed at the time of the first stabilization PR for target_features_11, and resulted in the following issues/PRs: * [`#[target_feature]` is allowed on `main` #108645](rust-lang/rust#108645) * [`#[target_feature]` is allowed on default implementations #108646](rust-lang/rust#108646) * [#[target_feature] is allowed on #[panic_handler] with target_feature 1.1 #109411](rust-lang/rust#109411) * [Prevent using `#[target_feature]` on lang item functions #115910](rust-lang/rust#115910) ## Documentation * Reference: [Document the `target_feature_11` feature reference#1181](rust-lang/reference#1181) --- cc tracking issue rust-lang/rust#69098 cc ```@workingjubilee``` cc ```@RalfJung``` r? ```@rust-lang/lang```
Cast allocas to default address space
Pointers for variables all need to be in the same address space for correct compilation. Therefore ensure that even if an `alloca` is created in a different address space, it is casted to the default address space before its value is used.
This is necessary for the amdgpu target and others where the default address space for `alloca`s is not 0.
For example the following code compiles incorrectly when not casting the address space to the default one:
```rust
fn f(p: *const i8 /* addrspace(0) */) -> *const i8 /* addrspace(0) */ {
let local = 0i8; /* addrspace(5) */
let res = if cond { p } else { &raw const local };
res
}
```
results in
```llvm
%local = alloca addrspace(5) i8
%res = alloca addrspace(5) ptr
if:
; Store 64-bit flat pointer
store ptr %p, ptr addrspace(5) %res
else:
; Store 32-bit scratch pointer
store ptr addrspace(5) %local, ptr addrspace(5) %res
ret:
; Load and return 64-bit flat pointer
%res.load = load ptr, ptr addrspace(5) %res
ret ptr %res.load
```
For amdgpu, `addrspace(0)` are 64-bit pointers, `addrspace(5)` are 32-bit pointers.
The above code may store a 32-bit pointer and read it back as a 64-bit pointer, which is obviously wrong and cannot work. Instead, we need to `addrspacecast %local to ptr addrspace(0)`, then we store and load the correct type.
Tracking issue: #135024
Reject `?Trait` bounds in various places where we unconditionally warned since 1.0 fixes #135730 fixes #135809 Also a breaking change, so let's see what crater says. This has been an unconditional warning since *before* 1.0
Mark condition/carry bit as clobbered in C-SKY inline assembly C-SKY's compare and some arithmetic/logical instructions modify condition/carry bit (C) in PSR, but there is currently no way to mark it as clobbered in `asm!`. This PR marks it as clobbered except when [`options(preserves_flags)`](https://doc.rust-lang.org/reference/inline-assembly.html#r-asm.options.supported-options.preserves_flags) is used. Refs: - Section 1.3 "Programming model" and Section 1.3.5 "Condition/carry bit" in CSKY Architecture user_guide: https://github.com/c-sky/csky-doc/blob/9f7121f7d40970ba5cc0f15716da033db2bb9d07/CSKY%20Architecture%20user_guide.pdf > Under user mode, condition/carry bit (C) is located in the lowest bit of PSR, and it can be accessed and changed by common user instructions. It is the only data bit that can be visited under user mode in PSR. > Condition or carry bit represents the result after one operation. Condition/carry bit can be clearly set according to the results of compare instructions or unclearly set as some high-precision arithmetic or logical instructions. In addition, special instructions such as DEC[GT,LT,NE] and XTRB[0-3] will influence the value of condition/carry bit. - Register definition in LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/CSKY/CSKYRegisterInfo.td#L88 cc ```@Dirreke``` ([target maintainer](https://github.com/rust-lang/rust/blob/aa6f5ab18e67cb815f73e0d53d217bc54b0da924/src/doc/rustc/src/platform-support/csky-unknown-linux-gnuabiv2.md#target-maintainers)) r? ```@Amanieu``` ```@rustbot``` label +O-csky +A-inline-assembly
std: replace the `FromInner` implementation for addresses with private conversion functions Having these implementation available crate-wide means that platforms not using sockets for their networking code have to stub out the libc definitions required to support them. This PR moves the conversions to private helper functions that are only available where actually needed. I also fixed the signature of the function converting from a C socket address to a Rust one: taking a reference to a `sockaddr_storage` resulted in unsound usage inside `LookupHost::next`, which could create a reference to a structure smaller than `sockaddr_storage`. Thus I've replaced the argument type with a pointer and made the function `unsafe`.
…compiler-errors Fix cycle when debug-printing opaque types from RPITIT Extend #66594 to opaque types from RPITIT. Before this PR, enabling debug logging like `RUSTC_LOG="[check_type_bounds]"` for code containing RPITIT produces a query cycle of `explicit_item_bounds`, as pretty printing for opaque type calls [it](https://github.com/rust-lang/rust/blob/d9a4a47b8b3dc0bdff83360cea2013200d60d49c/compiler/rustc_middle/src/ty/print/pretty.rs#L1001).
…eongeforce, r=bjorn3 compiler: internally merge `PtxKernel` into `GpuKernel` r? ``@bjorn3`` for review
Implement `read*_exact` for `std:io::repeat` cc #136756
…r=notriddle Correctly escape hashtags when running `invalid_rust_codeblocks` lint Fixes #136899. We forgot to use `map_line` when we wrote this lint. r? ``@notriddle``
Update books ## rust-lang/book 1 commits in e2fa4316c5a7c0d2499c5d6b799adcfad6ef7a45..d4d2c18cbd20876b2130a546e790446a8444cb32 2025-02-12 16:22:54 UTC to 2025-02-12 16:22:54 UTC - Fix example for `cargo fix` (rust-lang/book#4226) ## rust-lang/reference 3 commits in de2d5289e45506b11dd652bef4f99de64be70e1c..6195dbd70fc6f0980c314b4d23875ac570d8253a 2025-02-12 15:40:30 UTC to 2025-02-11 20:35:17 UTC - Revert "Update function-pointer.md for stabilization of `extended_varargs_abi_support`" (rust-lang/reference#1734) - Rework error handling in mdbook-spec (rust-lang/reference#1733) - `as` cast improvements (rust-lang/reference#1732)
Add diagnostic item for `std::io::BufRead` This will be used in Clippy to detect unbuffered calls to `Read::bytes()`.
…rcote Reinstate nnethercote in the review rotation. I'm back from vacation. r? ``@nnethercote``
This was unused after the removal of `-Zprofile` in #131829.
Rollup of 12 pull requests Successful merges: - #134090 (Stabilize target_feature_11) - #135025 (Cast allocas to default address space) - #135841 (Reject `?Trait` bounds in various places where we unconditionally warned since 1.0) - #136217 (Mark condition/carry bit as clobbered in C-SKY inline assembly) - #136699 (std: replace the `FromInner` implementation for addresses with private conversion functions) - #136806 (Fix cycle when debug-printing opaque types from RPITIT) - #136807 (compiler: internally merge `PtxKernel` into `GpuKernel`) - #136818 (Implement `read*_exact` for `std:io::repeat`) - #136927 (Correctly escape hashtags when running `invalid_rust_codeblocks` lint) - #136937 (Update books) - #136945 (Add diagnostic item for `std::io::BufRead`) - #136947 (Reinstate nnethercote in the review rotation.) r? `@ghost` `@rustbot` modify labels: rollup
When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
This changes the path from "licences" to "licenses" for consistency across the repo, including the usage directly around this line. This is a US/UK spelling difference, but I believe the US spelling is also more common in open source in general. (cherry picked from commit d183da6)
[beta] backports - CI: Stop /msys64/bin from being prepended to PATH in msys2 shell #136815 - Install licenses into `share/doc/rust/licenses` #138412 r? cuviper
[stable] Prepare Rust 1.86.0 r? ghost
* add ci * run on pr * specify branch * use ref * fix repo name * use nightly toolchain * use cargo native static * fix ci build * do a bad bad thing * remove stage 2 ci check * use ci branch * add release * disable gh action env * fix * fix archive * fix ubuntu runner * finalize
This matches the toolchain used by Jolt in this PR: a16z/jolt#510 The compiler is updated to align with features used by Binius (in particular the use of `iter::repeat_n`)
* add aarch64-unknown-linux-gnu triple to release * produce stable binaries
sagar-a16z
force-pushed
the
sagar/upgrade_rust
branch
from
7b224d6 to
6fdab16
Compare
sagar-a16z
force-pushed
the
sagar/upgrade_rust
branch
from
6fdab16 to
994bd60
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 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.
No description provided.