Open
Conversation
Big query system cleanups Recent PRs have moved a lot of code from `rustc_query_system` to `rustc_middle` and `rustc_query_impl`, where this code now has access to `TyCtxt`, e.g. rust-lang/rust#152419, rust-lang/rust#152516. As a result, a lot of abstraction and indirection that existed to work around this limitation is no longer necessary. This PR removes a lot of it. r? @Zalathar
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
…rtdev stdarch subtree update Subtree update of `stdarch` to a894c23. Created using https://github.com/rust-lang/josh-sync. r? @ghost
x86: support passing `u128`/`i128` to inline assembly tracking issue: rust-lang/rust#133416 Seems like an oversight. LLVM has supported this since 2019, see llvm/llvm-project#42502. I've put this under `asm_experimental_reg`. cc @taiki-e r? @Amanieu
Suggest local variables for captured format args Fixes rust-lang/rust#114108
Respect the `--ci` flag in more places in bootstrap ### Motivation Currently, the way of checking CI environment in bootstrap is not unified. Sometimes `--ci` flag is respected, but in other cases only GITHUB_ACTIONS env var is checked. ### Change This PR modifies the way of treating the flag in bootstrap. If `--ci` (or `--ci=true`) is added, bootstrap's config set ci_env as `CiEnv::GithubActions`. This PR also modifies some lines in bootstrap to respect the config's CiEnv instance. ### Note I haven't touched anything in tidy, because I want to raise another PR for introducing --ci flag in tidy. In the PR, I will need to change how tidy treats CI information. So currently I leave it as it is.
Fix ICE in transmutability error reporting when type aliases are normalized Fixes rust-lang/rust#151462 Transmutability error reporting hit an ICE when type aliases were normalized for diagnostics. For example, when type `JustUnit = ()` normalizes to `()`, the check passes unexpectedly even though the original check with `JustUnit` failed. Fixed by adding a retry in the `Answer::Yes` arm that checks with the root obligation's types before panicking. The retry only occurs when the root obligation differs and is a Transmute trait predicate. Also added a test that reproduces the original ICE.
Reflection TypeKind::FnPtr This is for rust-lang/rust#146922. Const-eval currently lacks full support for function pointer (fn) types. We should implement handling of FnPtr TypeKind, covering safe and unsafe functions, Rust and custom ABIs, input and output types, higher-ranked lifetimes, and variadic functions.
Remove unnecessary closure. The comments that says it's necessary is wrong. r? @adwinwhite
tests: rustc_public: Check const allocation for all variables (1 of 11 was missing)
In the test `tests/ui-fulldeps/rustc_public/check_allocation.rs` there is a check for constant allocations of local variables of this function:
fn other_consts() {{
let _max_u128 = u128::MAX;
let _min_i128 = i128::MIN;
let _max_i8 = i8::MAX;
let _char = 'x';
let _false = false;
let _true = true;
let _ptr = &BAR;
let _null_ptr: *const u8 = NULL;
let _tuple = TUPLE;
let _char_id = const {{ type_id::<char>() }};
let _bool_id = const {{ type_id::<bool>() }};
}}
The current test only finds 10 out of 11 allocations. The constant allocation for
let _ptr = &BAR;
is not checked, because the `SingleUseConsts` MIR pass does not optimize away that assignment. Add code to also collect constant allocation from assignment rvalues to find the constant allocation for that last variable.
Not only does this change make sense on its own, it also makes the test pass both with and without the `SingleUseConsts` pass.
Discovered while investigating ways to avoid [this tests/ui-fulldeps/rustc_public/check_allocation.rs](Enselic/rust@d7fffab#diff-c4a926f9e8ba22bcfb1e6f2491b79b80608ab018641f85f66d6718d7f3716a5e) hack from rust-lang/rust#151426 which wants to stop running `SingleUseConsts` for non-optimized builds.
compiletest: normalize stderr before SVG rendering Element position is hardcoded in the rendered SVG. This means that any change in element length (for instance, when substituting the path with the `rust` checkout with `$DIR`) would not change the position and result in buggy SVG being generated. Normalizing before SVG rendering allows us to keep a consistent element placement.
std::r#try! - avoid link to nightly docs Use a relative link to the current version of rust-by-example rather than sending people to the nightly version.
Remove some clones in deriving Just factoring away a few `.clone()`s.
Add a mir-opt test for alignment check generation [zero changes outside tests] I wrote this as part of rust-lang/rust#152641 which it looks like I'm going to just close, so submitting the new test separately since we didn't have any mir-opt testing of this pass that I could find (at least `x test tests/mir-opt` didn't fail when I broke them) so figured it's something that should exist.
Fix incorrect target in aarch64-unknown-linux-gnu docs Very minor thing, but the target should be `-gnu` instead of `-musl`.
Fix an ICE while checking param env shadowing on an erroneous trait impl Fixes rust-lang/rust#152663
…henkov Do no add -no-pie on Windows Windows binaries are always position independent and Clang warns when trying to enable or disable that: ``` ❯ clang hello.c -pie clang: warning: argument unused during compilation: '-pie' [-Wunused-command-line-argument] ❯ clang hello.c -no-pie clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument] ``` rust-lang/rust#149937 will turn these warnings into build errors: ``` ❯ cargo rustc -- -D linker-messages Compiling hello v0.1.0 (E:\tmp\hello) error: linker stderr: x86_64-w64-mingw32-clang: argument unused during compilation: '-nolibc' [-Wunused-command-line-argument]␍ x86_64-w64-mingw32-clang: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument]␍ | = note: requested on the command line with `-D linker-messages` error: could not compile `hello` (bin "hello") due to 1 previous error ```
…onathanBrouwer Avoid delayed-bug ICE for malformed diagnostic attrs Fixes rust-lang/rust#152744 Skip suggestions in `expected_lit` when parsing with `Recovery::Forbidden`, since this may later cancel `InvalidMetaItem`. This avoids creating delayed bugs that can be promoted to ICE.
interpret: fix comment typo Pointed out in rust-lang/rust#152756 (review) after that PR already had been rolled up.
…uwer Rollup of 18 pull requests Successful merges: - rust-lang/rust#152799 (Subtree sync for rustc_codegen_cranelift) - rust-lang/rust#152814 (stdarch subtree update) - rust-lang/rust#151059 (x86: support passing `u128`/`i128` to inline assembly) - rust-lang/rust#152097 (Suggest local variables for captured format args) - rust-lang/rust#152734 (Respect the `--ci` flag in more places in bootstrap) - rust-lang/rust#151703 (Fix ICE in transmutability error reporting when type aliases are normalized) - rust-lang/rust#152173 (Reflection TypeKind::FnPtr) - rust-lang/rust#152564 (Remove unnecessary closure.) - rust-lang/rust#152628 (tests: rustc_public: Check const allocation for all variables (1 of 11 was missing)) - rust-lang/rust#152658 (compiletest: normalize stderr before SVG rendering) - rust-lang/rust#152766 (std::r#try! - avoid link to nightly docs) - rust-lang/rust#152780 (Remove some clones in deriving) - rust-lang/rust#152787 (Add a mir-opt test for alignment check generation [zero changes outside tests]) - rust-lang/rust#152790 (Fix incorrect target in aarch64-unknown-linux-gnu docs) - rust-lang/rust#152792 (Fix an ICE while checking param env shadowing on an erroneous trait impl) - rust-lang/rust#152793 (Do no add -no-pie on Windows) - rust-lang/rust#152803 (Avoid delayed-bug ICE for malformed diagnostic attrs) - rust-lang/rust#152806 (interpret: fix comment typo)
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.)
Bring back `enum DepKind`. *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152747)* It was removed in rust-lang/rust#115920 to enable it being moved to `rustc_query_system`, a move that has recently been reversed. It's much simpler as an enum. r? @Zalathar
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.
…=estebank Try to recover from over-parsing in const item with missing semicolon Fixes rust-lang/rust#151149 r? @estebank
…=RalfJung
perf(codegen): Restore `noundef` On `PassMode::Cast` Args In Rust ABI
### Summary:
#### Problem:
Small aggregate arguments passed via `PassMode::Cast` in the Rust ABI (e.g. `[u32; 2]` cast to `i64`) are missing `noundef` in the emitted LLVM IR, even when the type contains no uninit bytes:
```rust
#[no_mangle]
pub fn f(v: [u32; 2]) -> u32 { v[0] }
```
```llvm
; expected: define i32 @f(i64 noundef %0)
; actual: define i32 @f(i64 %0) ← noundef missing
```
This blocks LLVM from applying optimizations that require value-defined semantics on function arguments.
#### Root Cause:
`adjust_for_rust_abi` calls `arg.cast_to(Reg::Integer)`, which internally creates a `CastTarget` with `ArgAttributes::new()` — always empty. Any validity attribute that was present before the cast is silently dropped.
This affects all `PassMode::Cast` arguments and return values in the Rust ABI: plain arrays, newtype wrappers, and any `BackendRepr::Memory` type small enough to fit in a register.
A prior attempt (rust-lang/rust#127210) used `Ty`/`repr` attributes to detect padding.
#### Solution:
After `adjust_for_rust_abi`, iterate all `PassMode::Cast` args and the return value. For each, call `layout_is_noundef` on the original layout; if it returns `true`, set `NoUndef` on the `CastTarget`'s `attrs`.
`layout_is_noundef` uses only the computed layout — `BackendRepr`, `FieldsShape`, `Variants`, `Scalar::is_uninit_valid()` — and never touches `Ty` or repr attributes. **Anything it cannot prove returns `false`.**
Covered cases:
- `Scalar` / `ScalarPair` (both halves initialized, fields contiguous)
- `FieldsShape::Array` (element type recursively uninit-free)
- `FieldsShape::Arbitrary` with `Variants::Single` (fields cover `0..size` with no gaps, each recursively uninit-free) — handles newtype wrappers, multi-field structs, single-variant enums, `repr(transparent)`, `repr(C)` wrappers
Conservatively excluded with FIXMEs:
- Multi-variant enums (per-variant padding analysis needed)
- Foreign-ABI casts (cast target may exceed layout size, needs a size guard)
### Changes:
- `compiler/rustc_ty_utils/src/abi.rs`: add restoration loop after `adjust_for_rust_abi`; add `layout_is_noundef` and `fields_cover_layout`.
- `tests/codegen-llvm/abi-noundef-cast.rs`: new FileCheck test covering arrays, newtype wrappers (`repr(Rust)`, `repr(transparent)`, `repr(C)`), multi-field structs, single-variant enums, return values, and negative cases (`MaybeUninit`, struct with trailing padding).
- `tests/codegen-llvm/debuginfo-dse.rs`: update one CHECK pattern — `Aggregate_4xi8` (`struct { i8, i8, i8, i8 }`) now correctly gets `noundef`.
Fixes rust-lang/rust#123183.
r? @RalfJung
…rtdev stdarch subtree update Subtree update of `stdarch` to d4a226d. Created using https://github.com/rust-lang/josh-sync. r? @ghost
…gau,jhpratt
Parse `impl` restrictions
This PR implements the parsing logic for `impl` restrictions (e.g., `pub impl(crate) trait Foo {}`) as proposed in [RFC 3323](https://rust-lang.github.io/rfcs/3323-restrictions.html).
As the first step of the RFC implementation, this PR focuses strictly on the parsing phase. The new syntax is guarded by the `#![feature(impl_restriction)]` feature gate.
This implementation basically follows the pattern used in rust-lang/rust#141754.
r? @jhpratt
…lts, r=nnethercote Replace CodegenResults with CompiledModules This is already CodegenResults without CrateInfo. The driver can calculate the CrateInfo and pass it by-ref to the backend. Using CompiledModules makes it a bit easier to move some other things out of the backend as will be necessary for moving LTO to the link phase. Helps with rust-lang/compiler-team#908
…lkertdev
Update call-llvm-intrinsics test for Rust 1.94.0 IR
Rust 1.94 now passes constants directly to llvm.sqrt.f32 instead of
storing/loading via the stack.
- Updated the FileCheck pattern to match the new IR:
// CHECK: call float @llvm.sqrt.f32(float 4.000000e+00)
The test intent is unchanged: it still ensures the intrinsic is
emitted as a 'call' (not 'invoke').
- Removed unnecessary local variables and Drop usage to work in
`#![no_core]` mode with minicore.
- Added required crate attributes:
#![feature(no_core, lang_items)]
#![no_std]
#![no_core]
- Replaced `//@ only-riscv64` (host-based execution) with explicit
revisions for:
riscv32gc-unknown-linux-gnu
riscv64gc-unknown-linux-gnu
This ensures deterministic multi-target coverage in CI without
relying on the host architecture.
- Added `//@ needs-llvm-components: riscv` and
`//@ min-llvm-version: 21` for CI compatibility.
Fixes rust-lang/rust#153271
Comments and docs: add missing periods to "ie." "i.e." is short for the Latin "id est" and thus both letters should be followed by periods.
Make `rustc_with_all_queries!` pass query modifiers as named values
This PR is a bold overhaul of how the proc-macro in `rustc_macros::query` passes query modifiers to the callback macros in `rustc_middle` and `rustc_query_impl`.
The existing approach passes modifiers as a list that looks like `[(arena_cache), (no_hash)]`. That style requires a family of helper macros (`if_arena_cache!`, `if_no_hash!`) to check for modifiers when consuming the query list.
This PR changes the proc-macro to instead pass modifiers like this:
```text
{
anon: false,
arena_cache: true,
cache_on_disk: false,
...
}
```
This style allows each of the callback macros to deconstruct the modifier list in a relatively straightforward way, by binding the true/false literals to variables like `$arena_cache:literal`.
One of the big advantages of this style is that we can write things like `#[cfg($arena_cache)]` and `#[cfg(not($arena_cache))]` to select blocks of code, eliminating the need for the `if_arena_cache!` family of helper macros.
In follow-up PRs, we can also try to take advantage of the new modifier style to pass richer information for some modifiers, such as `desc` or `cache_on_disk_if`. That could potentially make it more reasonable to get rid of the `_description_fns` and `_cache_on_disk_if_fns` modules, as proposed in rust-lang/rust#153065.
r? nnethercote
…uwer Rollup of 6 pull requests Successful merges: - rust-lang/rust#153336 (stdarch subtree update) - rust-lang/rust#152943 (Parse `impl` restrictions) - rust-lang/rust#153184 (Replace CodegenResults with CompiledModules) - rust-lang/rust#153285 (Update call-llvm-intrinsics test for Rust 1.94.0 IR) - rust-lang/rust#153319 (Comments and docs: add missing periods to "ie.") - rust-lang/rust#153326 (Make `rustc_with_all_queries!` pass query modifiers as named values)
…tfe, r=RalfJung Do not deduce parameter attributes during CTFE *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/151842)* Ever since rust-lang/rust#103172, `fn_abi_of_instance` might look at a function's body to deduce certain codegen optimization attributes for its indirectly-passed parameters beyond what can be determined purely from its signature (namely today `ArgAttribute::ReadOnly` and `ArgAttribute::CapturesNone`). Since rust-lang/rust#130201, looking at a function's body in this way entails generating, for any coroutine-closures, additional by-move MIR bodies (which aren't represented in the HIR)—but this requires knowing the types of their context and consequently cycles can ensue if such bodies are generated before typeck is complete (such as during CTFE). Since they have no bearing on the evaluation result, this patch breaks a subquery out from `fn_abi_of_instance`, `fn_abi_of_instance_no_deduced_attrs`, which returns the ABI before such parameter attributes are deduced; and that new subquery is used in CTFE instead (however, since parameter attributes are only deduced in optimized builds, as a performance optimization we avoid calling the original query unless we are performing such a build). Fixes rust-lang/rust#151748 Fixes rust-lang/rust#152497
…Jung Implement `MaybeDangling` compiler support Tracking issue: rust-lang/rust#118166 cc @RalfJung
(cherry picked from commit bad24ccbeceb787d2ad62847196315576a0d4fc7)
Bootstrap update - Replace version placeholders with 1.95.0 - Bump stage0 to 1.95.0-beta.1 - Clear `STAGE0_MISSING_TARGETS` - Update `cfg(bootstrap)` - Reformat with the new stage0
Gate #![reexport_test_harness_main] properly Address the FIXME Removed from `issue-43106-gating-of-builtin-attrs.rs` since that is for stable attributes only. This would be a breaking change, search of github shows it is mostly but not always used with `#![test_runner]` which is already gated correctly. Details: rust-lang/rust#50297 Feel free to close this issue if you think it is not worth addressing the FIXME...
…uwer Rollup of 2 pull requests Successful merges: - rust-lang/rust#153462 (Bootstrap update) - rust-lang/rust#152210 (Gate #![reexport_test_harness_main] properly)
Don't use incremental disk-cache for query `predicates_of` The `predicates_of` query is a relatively modest wrapper around a few underlying queries that are themselves cached to disk. Removing the additional layer of disk caching appears to be a significant perf win. This query also appears to be the only query that uses a crate-local `cache_on_disk_if` condition, without also using the `separate_provide_extern` modifier. - Discovered via rust-lang/rust#153487 (comment)
Overhaul `ensure_ok` The interaction of `ensure_ok` and the `return_result_from_ensure_ok` query modifier is weird and hacky. This PR cleans it up. Details in the individual commits. r? @Zalathar
This updates the rust-version file to eda4fc7733ee89e484d7120cafbd80dcb2fce66e.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@eda4fc7 Filtered ref: 3f3adc6 Upstream diff: rust-lang/rust@1396514...eda4fc7 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
r? @folkertdev rustbot has assigned @folkertdev. Use Why was this reviewer chosen?The reviewer was selected based on:
|
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
5 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.