Merged
Conversation
At this point module `ich` is the only thing left.
Remove `rustc_query_system` The end point of the PR sequence rust-lang/rust#152160, rust-lang/rust#152419, rust-lang/rust#152516. r? @Zalathar
misc doc improvements These are things I collected as I was looking at code and docs
…omez Fix mis-constructed `file_span` when generating scraped examples Fixes rust-lang/rust#152601. Seemingly relative with rust-lang/rust#147399 but I could not reproduce the original ICE. This PR removes the `file_span` logic from scraped example generation. The original implementation did not read or write items using `file_span`; it only used it to locate a source file, `context.href_from_span`. However, the span was validated against the wrong file, which could trigger ICEs on inputs such as multibyte characters due to an incorrectly constructed span. Since scraped examples do not use the span and the `url` is already given, the safest and simplest fix is to remove it. Tested against the crate and MCVE documented in the original issue. P.S. there seems to be some bug when rendering call sites, but since fixing mis-behavior is a change rather than a bug-fix that would be implemented in another PR.
Suppress unstable-trait notes under `-Zforce-unstable-if-unmarked` - Fixes rust-lang/rust#152692. --- rust-lang/rust#151036 adds extra diagnostic text (“the nightly-only, unstable trait”) to note when a not-implemented trait is unstable. However, that extra text is usually unhelpful when building a crate graph with `-Zforce-unstable-if-unmarked` (such as the compiler or stdlib), because *any* trait not explicitly marked stable will be treated as unstable. (For typical compiler contributors using the stage0 compiler, this fix won't take effect until the next bootstrap beta bump.)
`probe_op` silence ambiguity errors if tainted see the `proc-macro/quote/not-repeatable.rs` test for a case where this is useful r? types
Port #![default_lib_allocator] to the new attribute parser Tracking issue: rust-lang/rust#131229 r? @JonathanBrouwer
Rollup of 11 pull requests Successful merges: - rust-lang/rust#152700 (miri subtree update) - rust-lang/rust#152715 (`rust-analyzer` subtree update) - rust-lang/rust#151783 (Implement RFC 3678: Final trait methods) - rust-lang/rust#152512 (core: Implement feature `float_exact_integer_constants`) - rust-lang/rust#152661 (Avoid ICE in From/TryFrom diagnostic under -Znext-solver) - rust-lang/rust#152703 (Remove `rustc_query_system`) - rust-lang/rust#152206 (misc doc improvements) - rust-lang/rust#152664 (Fix mis-constructed `file_span` when generating scraped examples) - rust-lang/rust#152698 (Suppress unstable-trait notes under `-Zforce-unstable-if-unmarked`) - rust-lang/rust#152727 (`probe_op` silence ambiguity errors if tainted) - rust-lang/rust#152728 (Port #![default_lib_allocator] to the new attribute parser)
…rochenkov,jieyouxu Fix wrong par_slice implementation rust-lang/rust#152375 (comment)
…ti865
Revert "Fix an ICE in the vtable iteration for a trait reference"
The ICE fix appears to be unsound, causing a miscompilation involving `dyn Trait` and `async {}` which induces segfaults in safe Rust code. As the patch only hid an ICE, it does not seem worth the risk.
This addresses the problem in rust-lang/rust#152735 but it may still merit team discussion even if this PR is merged.
This reverts commit 8afd63610b0a261d3c39e24140c6a87d3bff075c, reversing changes made to 19122c03c7bea6bde1dfa5c81fca5810953d9f39.
…,jieyouxu Support JSON target specs in bootstrap JSON target specs were destabilized in rust-lang/rust#150151 and rust-lang/rust#151534. However, this broke trying to build rustc itself with a JSON target spec. This is because in a few places bootstrap is manually calling `rustc` without the ability for the user to provide additional flags (primarily, `-Zunstable-options` to enable JSON targets). There's a few different ways to fix this. One would be to change these calls to `rustc` to include flags provided by the user (such as `RUSTFLAGS_NOT_BOOTSTRAP`). Just to keep things simple, this PR proposes to just unconditionally pass `-Zunstable-options`. Another consideration here is how maintainable this is. A possible improvement here would be to have a function somewhere (BootstrapCommand, TargetSelection, free function) that would handle appropriately adding the `--target` flag. For example, that's what cargo does in [`CompileKind::add_target_arg`](https://github.com/rust-lang/cargo/blob/592058c7ce08a2ba2628b01e7dc4ce1e72b6bdff/src/cargo/core/compiler/compile_kind.rs#L144-L154). I have only tested building the compiler and a few tools like rustdoc. I have not tested doing things like building other tools, running tests, etc. This would be much easier if there was a Docker image for testing the use case of building rustc with a custom target spec (and even better if that ran in CI). After the next beta branch, using target JSON specs will become more cumbersome because target specs with the `.json` extension will now require passing `-Zjson-target-spec` (from rust-lang/cargo#16557). This does not affect target specs without the `.json` extension (such as those from RUST_TARGET_PATH). From my testing, it should be sufficient to pass `CARGOFLAGS_NOT_BOOTSTRAP="-Zjson-target-spec"`. I think that should be fine, since this is not a particularly common use case AFAIK. We could extend bootstrap to auto-detect if the target is a file path, and pass `-Zjson-target-spec` appropriately. I tried something similar in ehuss/rust@f0bdd35, which could be adapted if desired. It would be nice if all of this is documented somewhere. https://rustc-dev-guide.rust-lang.org/building/new-target.html does not really say how to build the compiler with a custom json target. Fixes rust-lang/rust#151729
Stabilize `if let` guards (`feature(if_let_guard)`) ## Summary This proposes the stabilization of `if let` guards (tracking issue: rust-lang/rust#51114, RFC: rust-lang/rfcs#2294). This feature allows `if let` expressions to be used directly within match arm guards, enabling conditional pattern matching within guard clauses. ## What is being stabilized The ability to use `if let` expressions within match arm guards. Example: ```rust enum Command { Run(String), Stop, Pause, } fn process_command(cmd: Command, state: &mut String) { match cmd { Command::Run(name) if let Some(first_char) = name.chars().next() && first_char.is_ascii_alphabetic() => { // Both `name` and `first_char` are available here println!("Running command: {} (starts with '{}')", name, first_char); state.push_str(&format!("Running {}", name)); } Command::Run(name) => { println!("Cannot run command '{}'. Invalid name.", name); } Command::Stop if state.contains("running") => { println!("Stopping current process."); state.clear(); } _ => { println!("Unhandled command or state."); } } } ``` ## Motivation The primary motivation for `if let` guards is to reduce nesting and improve readability when conditional logic depends on pattern matching. Without this feature, such logic requires nested `if let` statements within match arms: ```rust // Without if let guards match value { Some(x) => { if let Ok(y) = compute(x) { // Both `x` and `y` are available here println!("{}, {}", x, y); } } _ => {} } // With if let guards match value { Some(x) if let Ok(y) = compute(x) => { // Both `x` and `y` are available here println!("{}, {}", x, y); } _ => {} } ``` ## Implementation and Testing The feature has been implemented and tested comprehensively across different scenarios: ### Core Functionality Tests **Scoping and variable binding:** - [`scope.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs) - Verifies that bindings created in `if let` guards are properly scoped and available in match arms - [`shadowing.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs) - Tests that variable shadowing works correctly within guards - [`scoping-consistency.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/scoping-consistency.rs) - Ensures temporaries in guards remain valid for the duration of their match arms **Type system integration:** - [`type-inference.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/type-inference.rs) - Confirms type inference works correctly in `if let` guards - [`typeck.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/typeck.rs) - Verifies type mismatches are caught appropriately **Pattern matching semantics:** - [`exhaustive.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/exhaustive.rs) - Validates that `if let` guards are correctly handled in exhaustiveness analysis - [`move-guard-if-let.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let.rs) and [`move-guard-if-let-chain.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs) - Test that conditional moves in guards are tracked correctly by the borrow checker ### Error Handling and Diagnostics - [`warns.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/warns.rs) - Tests warnings for irrefutable patterns and unreachable code in guards - [`parens.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs) - Ensures parentheses around `let` expressions are properly rejected - [`macro-expanded.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs) - Verifies macro expansions that produce invalid constructs are caught - [`guard-mutability-2.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/guard-mutability-2.rs) - Tests mutability and ownership violations in guards - [`ast-validate-guards.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs) - Validates AST-level syntax restrictions ### Drop Order and Temporaries **Key insight:** Unlike `let_chains` in regular `if` expressions, `if let` guards do not have drop order inconsistencies because: 1. Match guards are clearly scoped to their arms 2. There is no "else block" equivalent that could cause temporal confusion - [`drop-order.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/drop-order.rs) - Check drop order of temporaries create in match guards - [`compare-drop-order.rs`](https://github.com/rust-lang/rust/blob/aef3f5fdf052fbbc16e174aef5da6d50832ca316/tests/ui/rfcs/rfc-2294-if-let-guard/compare-drop-order.rs) - Compares drop order between `if let` guards and nested `if let` in match arms, confirming they behave identically across all editions - rust-lang/rust#140981 - A complicated drop order test involved `let chain` was made by @est31 - [`drop-order-comparisons-let-chains.rs`](https://github.com/rust-lang/rust/blob/902b4d28783e03e231d8513082cc30c4fcce5d95/tests/ui/drop/drop-order-comparisons-let-chains.rs) - Compares drop order between `let chains` in `if let guard` and regular `if` expressions - [`if-let-guards.rs`](https://github.com/rust-lang/rust/blob/5650d716e0589e2e145ce9027f35bd534e5f862a/tests/ui/drop/if-let-guards.rs) - Test correctness of drop order for bindings and temporaries - [`if-let-guards-2`](https://github.com/rust-lang/rust/blob/3a6c8c8f3d7ae654fdb6ce1255182bda21680655/tests/ui/drop/if-let-guards-2.rs) - The same test as above but more comprehensive and tests more interactions between different features and their drop order, checking that drop order is correct, created by @traviscross ## Edition Compatibility This feature stabilizes on all editions, unlike `let chains` which was limited to edition 2024. This is safe because: 1. `if let` guards don't suffer from the drop order issues that affected `let chains` in regular `if` expressions 2. The scoping is unambiguous - guards are clearly tied to their match arms 3. Extensive testing confirms identical behavior across all editions ## Interactions with Future Features The lang team has reviewed potential interactions with planned "guard patterns" and determined that stabilizing `if let` guards now does not create obstacles for future work. The scoping and evaluation semantics established here align with what guard patterns will need. ## Unresolved Issues - [x] - rust-lang/rust#140981 - [x] - added tests description by @jieyouxu request - [x] - Concers from @scottmcm about stabilizing this across all editions - [x] - check if drop order in all edition when using `let chains` inside `if let` guard is the same - [x] - interactions with guard patters - [x] - pattern bindings drops before guard bindings rust-lang/rust#143376 - [x] - documentaion (rust-lang/reference#1957) - [ ] (non-blocking) add tests for [this](rust-lang/rust#145237) and [this](rust-lang/rust#141295 (comment)) --- **Related:** - Tracking Issue: rust-lang/rust#51114 - RFC: rust-lang/rfcs#2294 - Documentation PR: rust-lang/reference#1957
Simplify the canonical enum clone branches to a copy statement
I have overhauled MatchBranchSimplification in this PR. This pass tries to unify statements one by one, which is more readable and extensible.
This PR also unifies the following pattern that is mostly generated by GVN into one basic block that contains the copy statement:
```rust
match a {
Foo::A(_) => *a,
Foo::B => Foo::B
}
```
Fixes rust-lang/rust#128081.
Perform many const checks in typeck Some smaller diagnostic changes, the biggest ones avoided by rust-lang/rust#148641 We should be able to move various checks in mir const checking to using `span_bug!` instead of reporting an error, just like mir typeck does as a sanity check. I would like to start doing so separately though, as this PR is a big enough (in what effects it causes, pun intended). r? @fee1-dead
…gillot Simplify `size/align_of_val<T: Sized>` to `size/align_of<T>` instead This is relevant to things like `Box<[u8; 1024]>` where the drop looks at the `size_of_val` (since obviously it might be DST in general) but where we don't actually need to do that since it's always that same value for the `Sized` type. (Equivalent to rust-lang/rust#152681, but flipped in the rebase so it can land before rust-lang/rust#152641 instead of depending on it.)
…alexcrichton For panic=unwind on Wasm targets, define __cpp_exception tag Since llvm/llvm-project#159143, llvm no longer weak links the __cpp_exception tag into each object that uses it. They are now defined in compiler-rt. Rust doesn't seem to get them from compiler-rt so llvm decides they need to be imported. This adds them to libunwind. Same changes applied to compiler-builtins: rust-lang/compiler-builtins#1077 See wasm-bindgen/wasm-bindgen#4938 for a downstream workaround. cc @sbc100
Do not cancel try builds after first job failure Suggested by @ZuseZ4, who was doing a bunch of parallel try builds recently. r? @marcoieni
…zelmann Remove the translation `-Z` options and the `Translator` type. This PR implements MCP rust-lang/compiler-team#967 It is split up into individually reviewable commits, each commit passes tests: * rust-lang/rust@6782119 Removes the translation compiler options from the session * rust-lang/rust@8f300d0 Removes the now empty `Translator` type * rust-lang/rust@ab715c5 Renames `translate_message` to `format_diag_message`, as the function no longer does any translation * rust-lang/rust@8bcbc3f Removes a section describing the removed compiler options from the rustc dev guide
Skip the `use_existential_projection_new_instead` field in the `Debug` impl Resolves: rust-lang/rust#152807 . Simply slap a `#derive_where[skip(Debug)]` on that field.
Expose Span for all DefIds in rustc_public Part of rust-lang/project-stable-mir#118 To be maximally useful, `VariantDef` and `FieldDef` should be changed to be a wrapper around `DefId` instead of holding their parent and index. I can do this change in this PR or a follow-up if it is desired. For now, I added the missing `impl Stable for DefId` in internals so you can convert from rustc internals.
…uwer Rollup of 9 pull requests Successful merges: - rust-lang/rust#146832 (Not linting irrefutable_let_patterns on let chains) - rust-lang/rust#146972 (Support importing path-segment keyword with renaming) - rust-lang/rust#152241 (For panic=unwind on Wasm targets, define __cpp_exception tag) - rust-lang/rust#152527 (Remove -Zemit-thin-lto flag) - rust-lang/rust#152769 (Do not cancel try builds after first job failure) - rust-lang/rust#152907 (Add tests for delegation generics) - rust-lang/rust#152455 (Remove the translation `-Z` options and the `Translator` type. ) - rust-lang/rust#152813 (Skip the `use_existential_projection_new_instead` field in the `Debug` impl) - rust-lang/rust#152912 (Expose Span for all DefIds in rustc_public)
Audit Symbols *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152624)* Remove unused symbols and hoist some symbols to Clippy.
Update cargo submodule 10 commits in ce69df6f72a3b6a2b5c722ba68ddef255344b31c..8cc0cb136772b8f54eafe0d163fcb7226a06af0c 2026-02-12 12:39:45 +0000 to 2026-02-17 12:16:26 +0000 - docs(layout): Updated layout module docs to document new layout (rust-lang/cargo#16502) - fix(host-config): host.linker should not apply to non host unit (rust-lang/cargo#16641) - init: improve error message and add tests (rust-lang/cargo#16643) - Corrected doc comment for build script root_output path (rust-lang/cargo#16645) - Changed build script run `output` dir to `stdout` in new build-dir layout (rust-lang/cargo#16644) - test: add test case for verify-project with invalid TOML (rust-lang/cargo#16640) - test(script): Show remaining workspace behavors (rust-lang/cargo#16633) - fix(host-config): `host.runner` should not apply to `cargo run` (rust-lang/cargo#16638) - refactor(help): simplify code structure (rust-lang/cargo#16627) - test: Remove unused docker ip_address (rust-lang/cargo#16636)
Just pass `Layout` directly to `box_new_uninit` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152737)* We have a constant for it already (used in `RawVec` for basically the same polymorphization) so let's use it. This is a simple follow-up to rust-lang/rust#148190 from one of the comments.
This updates the rust-version file to c78a29473a68f07012904af11c92ecffa68fcc75.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@c78a294 Filtered ref: 2f61036 Upstream diff: rust-lang/rust@1396514...c78a294 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
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
6 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.
Latest update from rustc.