Repository navigation
Rustc pull update - #2236
Merged
Merged
Rustc pull update#2236
Conversation
`funnel_shl` and `funnel_shr` have been around for close to a year, the
unchecked versions for a number of months. These are reasonably small
and uncontroversial, and it can be tricky to get similar performance
with a fallback; stabilize them here.
Newly stable API:
impl {u8, u16, u32, u64, u128, usize} {
pub const fn funnel_shl(self, right: Self, shift: u32) -> Self;
pub const fn funnel_shr(self, right: Self, shift: u32) -> Self;
pub const unsafe fn unchecked_funnel_shl(self, right: Self, shift: u32) -> Self;
pub const unsafe fn unchecked_funnel_shr(self, right: Self, shift: u32) -> Self;
}
The tracking issue also mentions a `wrapping_` version but it has not
been implemented.
Tracking issue: RUST-145686
…08, r=antoyo `rustc_codegen_gcc` subtree update r? antoyo
…rtdev stdarch subtree update Fixes rust-lang#2232 Subtree update of `stdarch` to rust-lang@cdcca32. Created using https://github.com/rust-lang/josh-sync. r? @ghost
…ethercote Build a new incr comp session dir from scratch every time Rather than copying the old incr comp dir and then modifying it. This saves a copy/hardlink for files that are modified. And it removes the need for accurate work product tracking to avoid accumulating cruft, which is non-trivial. We don't accurately track the pre-LTO bitcode files for ThinLTO for example. Part of rust-lang/compiler-team#908
Enable EII tests for cg_gcc
…uillaumeGomez cg_gcc subtree sync 2026-09-24 cc @antoyo r? ghost
avoid accessing uninferred closure upvars in diagnostics fixes rust-lang/rust#162440 `note_closure_capture` can run before closure capture analysis has finished and the upvar tuple may still be an inference variable at that point and calling `upvar_tys()` causes an ICE we can just fall back to the existing closure-level note and wait until the upvar types are available before trying to emit the more specific capture note
do generic_const_args Const::Ty hack only on projection consts Under `generic_const_args`, we currently do a bit of a hack to lower all consts to `Const::Ty`, because under `generic_const_args`, projection consts not marked with `#[rustc_always_gca]` could be `impl`'d by a const with a `gca!` rhs, and `Const::Unevaluated` does not support direct consts. Instead, only lower a const to `Const::Ty` if: - it is a direct const (under `min_generic_const_args`), OR - it is a projection const (under `generic_const_args`) This excludes all anon consts, and regular (not direct) free and inherent consts from being lowered as `Const::Ty` under full GCA. It does not fix the underlying issue that lowering a potentially regular projection const to `Const::Ty` is incorrect. Fixes rust-lang/rust#162923 Introduced in rust-lang/rust#162760 r? @BoxyUwU
…n-parens, r=khyperia Fix incorrect use of await in parser suggestion The old suggestion of: ```diff LL - let _ = await!(bar())?; LL + let _ = bar().await)?; ``` is wrong because of the lefted `)` was unremoved, and also here we need to take care of expr precedence.
…uwer Rollup of 7 pull requests Successful merges: - rust-lang/rust#163218 (stdarch subtree update) - rust-lang/rust#159287 (Build a new incr comp session dir from scratch every time) - rust-lang/rust#163222 (Enable EII tests for cg_gcc) - rust-lang/rust#163251 (cg_gcc subtree sync 2026-09-24) - rust-lang/rust#162595 (avoid accessing uninferred closure upvars in diagnostics) - rust-lang/rust#162937 (do generic_const_args Const::Ty hack only on projection consts) - rust-lang/rust#163238 (Fix incorrect use of await in parser suggestion)
Split region infer context into unsolved and frozen This helps us ensure that we don't accidentally modify things after we use them. r? lqd
Unflatten `use` statements in HIR
The HIR and AST representations of use statements are now mirrored, instead of having the HIR flatten the AST representation and duplicating early parts of nested paths:
```rust
use a::b::{c, d};
```
used to get flattened in HIR to
```rust
use a::b::c;
use a::b::d;
use a::b::{};
```
which duplicated the `a::b` part several times (and many more if you have more nesting).
This alone is fine, it made some parts of the compiler simpler and some parts harder, but it also meant we were generating more items (which are also owners) and had to duplicate resolver information across the flattened items. All that is gone with this PR.
This PR is the minimal version we can land, but there are obvious further avenues for cleanups and improvements. I did some refactorings in rustdoc, but I think the import logic can generally be improved by not handling imports together with other items and instead having them in separate tables.
Similarly clippy can probably benefit from a `check_use_tree` method on `LateLintPass`, but they often need to track separate information anyway, so it may be better to just always manually recurse.
should unblock rust-lang/rust#159760
see related discussion on [#t-compiler > partial_res_map vs per-owner tables @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/partial_res_map.20vs.20per-owner.20tables/near/602112306)
part of rust-lang/goals#620
Additional NonZero conversions ACP: rust-lang/libs-team#145 Requires FCP due to insta-stable APIs added: ```rust // can't be done generically; compiler can't infer that ZeroablePrimitive is sealed for coherence reasons impl From<&NonZero<uN>> for &uN; impl From<&NonZero<iN>> for &iN; impl From<&NonZero<usize>> for &usize; impl From<&NonZero<isize>> for &isize; impl From<&NonZero<char>> for &char; // excluded due to typechecking bug, but left commented out in code // impl<T> From<&[NonZero<T>]> for &[T] where T: ZeroablePrimitive; // rest are generic impl<T, const N: usize> From<[NonZero<T>; N]> for [T; N] where T: ZeroablePrimitive; impl<T> TryFrom<&T> for &NonZero<T> where T: ZeroablePrimitive; impl<T> TryFrom<&[T]> for &[NonZero<T>] where T: ZeroablePrimitive; impl<T, const N: usize> TryFrom<[T; N]> for [NonZero<T>; N] where T: ZeroablePrimitive; ``` Note that the `Error` for the `TryFrom` implementations is `TryFromIntError` to match the similar impls. r? rust-lang/libs-api
Stabilize `funnel_shifts` (including `const`)
`funnel_shl` and `funnel_shr` have been around for close to a year, the unchecked versions for a number of months. These are reasonably small and uncontroversial, and it can be tricky to get similar performance with a fallback; stabilize them here.
Newly stable API:
```rust
impl {u8, u16, u32, u64, u128, usize} {
pub const fn funnel_shl(self, right: Self, shift: u32) -> Self;
pub const fn funnel_shr(self, right: Self, shift: u32) -> Self;
pub const unsafe fn unchecked_funnel_shl(self, right: Self, shift: u32) -> Self;
pub const unsafe fn unchecked_funnel_shr(self, right: Self, shift: u32) -> Self;
}
```
The tracking issue also mentions a `wrapping_` version but it has not been implemented.
Closes: rust-lang/rust#145686 (tracking issue, wrapping versions will need a new issue)
Stabilize `Result::into_{ok,err}`
Tracking issue: rust-lang/rust#61695
---
As evidence of the demand of this API, here are some instances of people having written functions for this functionality:
* https://github.com/meteroid-oss/meteroid/blob/6cc14c4a444c6ae4889c603f5cb275ea626d7507/crates/common-utils/src/misc.rs#L7
* https://github.com/mokeyish/smartdns-rs/blob/788e83fa72477ebcf1c6a7f4482359353d29c480/src/server/http.rs#L93
* https://github.com/nostrdevkit/nostr/blob/ea38c0e3b2fc2717a4a55d019560a5574baf8cd0/nostr/src/util/mod.rs#L120
* https://github.com/ngrok/ngrok-rust/blob/3d5131559948ba9932dd0a450474fd1d19d206eb/ngrok/examples/tls.rs#L92
* https://github.com/octopii-rs/octopii/blob/b54c112d7db7ed1195dd4f600b4b786df85c8e7e/openraft/openraft/src/error/into_ok.rs#L10
* https://github.com/TeXitoi/keyseebee/blob/30956f62e618ed754c15af66f8ade70269fef89a/firmware/src/main.rs#L54
---
API being stabilized:
```rust
impl<T, E> Result<T, E> {
pub fn into_ok(self) -> T
where
E: Into<!>
{ .... }
pub fn into_err(self) -> E
where
T: Into<!>,
{ .... }
}
```
---
Implementation history: (I'm including only ones that touches the public API being stabilized, and not documentation or constification)
* rust-lang/rfcs#2799
* rust-lang/rust#66045
* rust-lang/rust#83421
* rust-lang/rust#92444
Add support for -Zsanitizer-cfi-minimal-runtime For production use, we should only link in the ubsan_minimal runtime, instead of the complete ubsan runtime. This adds support for both cfi-recover and cfi-diag to use the minimal runtime when `-Zsanitizer-cfi-minimal-runtime` is specified. This also includes tests, to ensure the flag can only be used if either cfi-recover or cfi-diag is enabled, it doesn't disrupt the original behavior, and links in the correct runtime when specified. cc @1c3t3a ?r rcvalle
implement #![feature(gca_adts)] Tracking issue: rust-lang/rust#163420 r? @BoxyUwU
…ute-documentation, r=clarfonthey add `automatically_derived` attribute documentation Documents the `automatically_derived` built-in attribute in `core` via `#[doc(attribute = "automatically_derived")]` Part of rust-lang/rust#157604
…enkov do not complain about unstable target features on nightly This was brought up in rust-lang/rust#162235 (comment): we currently print a warning on nightly saying that using an unstable target feature will become a hard error. That's a mistake. We could either remove the part of the warning that talks about it becoming a hard error, or we could just hide the warning entirely for unstable features on nighty. I went for the latter -- nightly is meant for experimentation with those features so having un-silenceable warnings is not great. Cc @workingjubilee
Add `stable_rustc` helper in `run-make-support` To help with rust-lang/rust#162848 and https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/626329887. For rust-lang/rust#162848, I need to avoid passing `-Zthreads` when the compiler is supposed to act like `stable`. This refactoring makes that simpler; I will only add that flag to `Rustc::new` and not `Rustc::stable`. r? jieyouxu
…trochenkov Allow using different index types when reading and writing to tables Make tables of metadata two-sided: one can write with one index type and read with another, as long as both those types are indexes. That will be used in rust-lang/rust#163321 when we will have `LocalDefIndex` or similar type. r? @petrochenkov
…-kruppe Stabilize vec_try_remove Closes rust-lang/rust#146954 , which is has [completed its FCP with disposition to merge](rust-lang/rust#146954 (comment)). Hello, this is my first contribution to Rust! I was programming for fun this weekend and I was surprised that this wasn't stabilized, so I thought I would try to contribute. Disclosure: I am making this PR in my capacity as a Canonical employee. No LLMs were harmed in the making of this pull request.
Rollup of 9 pull requests Successful merges: - rust-lang/rust#161015 (Stabilize `funnel_shifts` (including `const`)) - rust-lang/rust#161712 (Stabilize `Result::into_{ok,err}`) - rust-lang/rust#162493 (Add support for -Zsanitizer-cfi-minimal-runtime) - rust-lang/rust#163427 (implement #![feature(gca_adts)]) - rust-lang/rust#163390 (add `automatically_derived` attribute documentation) - rust-lang/rust#163428 (do not complain about unstable target features on nightly) - rust-lang/rust#163444 (Add `stable_rustc` helper in `run-make-support`) - rust-lang/rust#163447 (Allow using different index types when reading and writing to tables) - rust-lang/rust#163459 (Stabilize vec_try_remove)
Specialize `advance_back_by` like the forward version We specialized `advance_by` in rust-lang/rust#141086, so it makes sense to have `advance_back_by` use the same trick in reverse, i.e. `try_rfold`. This also updates `nth_back` to mirror `nth`, and the rest of the `DoubleEndedIterator` methods already match `Iterator`.
Apply LTO to Cranelift and GCC codegen backends Before we didn't use the LTO config for them at all.
add relnotes 1.99.0 r? mark-simulacrum cc @rust-lang/release
This updates the rust-version file to 21b707e3f97e0b522ebd2f277a862339625ad83f.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 21b707e3f97e0b522ebd2f277a862339625ad83f Filtered ref: 409f942 Upstream diff: rust-lang/rust@220b36c...21b707e This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
r? @davidtwco rustbot has assigned @davidtwco. Use Why was this reviewer chosen?The reviewer was selected based on:
|
Member
|
Fyi it looks like you might be using an old version of josh-sync, since it's not adding |
Contributor
Author
|
probably. Apparently the commit associated with |
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
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.
Merge ref '21b707e3f97e' from rust-lang/rust
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: 21b707e3f97e0b522ebd2f277a862339625ad83f
Filtered ref: 409f942
Upstream diff: rust-lang/rust@220b36c...21b707e
This merge was created using https://github.com/rust-lang/josh-sync.