about summary refs log tree commit diff
path: root/tests/mir-opt/building
AgeCommit message (Collapse)AuthorLines
2025-09-17Rollup merge of #146564 - cjgillot:mir-nolen, r=scottmcmStuart Cook-4/+581
Remove Rvalue::Len again. Now that we have `RawPtrKind::FakeForPtrMetadata`, we can reimplement `Rvalue::Len` using `PtrMetadata(&raw const (fake) place)`. r? ``@scottmcm``
2025-09-16Do not renumber resume local.Camille Gillot-79/+76
2025-09-16Add test.Camille Gillot-6/+448
2025-09-16Add test.Camille Gillot-0/+571
2025-09-16Remove Rvalue::Len.Camille Gillot-4/+10
2025-09-01Auto merge of #144783 - folkertdev:loop-match-diverging-loop, r=SparrowLiibors-0/+369
fix `#[loop_match]` on diverging loop tracking issue: https://github.com/rust-lang/rust/issues/132306 fixes https://github.com/rust-lang/rust/issues/144492 fixes https://github.com/rust-lang/rust/issues/144493 fixes https://github.com/rust-lang/rust/issues/144781 this generated invalid MIR before. issue https://github.com/rust-lang/rust/issues/143806 still has an issue where we assign `state = state` which is invalid in MIR. Fixing that problem is tricky, so I'd like to do that separately. r? `@bjorn3`
2025-08-26Use -Zmir-opt-level=0 in tests for MIR buildingBen Kimock-47/+69
2025-08-11Convert moves of references to copies in RefPropBen Kimock-1/+1
2025-08-10add place mention for `#[loop_match]` scrutineeFolkert de Vries-0/+369
2025-08-07Rollup merge of #143028 - dianne:let-else-storage, r=oli-obk,traviscrossStuart Cook-9/+5
emit `StorageLive` and schedule `StorageDead` for `let`-`else`'s bindings after matching This PR removes special handling of `let`-`else`, so that `StorageLive`s are emitted and `StorageDead`s are scheduled only after pattern-matching has succeeded. This means `StorageDead`s will no longer appear for all of its bindings on the `else` branch (because they're not live yet) and its drops&`StorageDead`s will happen together like they do elsewhere, rather than having all drops first, then all `StorageDead`s. This fixes rust-lang/rust#142056, and is therefore a breaking change. I believe it'll need a crater run and a T-lang nomination/fcp thereafter. Specifically, this makes drop-checking slightly more restrictive for `let`-`else` to match the behavior of other variable binding forms. An alternative approach could be to change the relative order of drops and `StorageDead`s for other binding forms to make drop-checking more permissive, but making that consistent would be a significantly more involved change. r? mir cc `````@dingxiangfei2009````` `````@rustbot````` label +T-lang +needs-crater
2025-08-04Dont print arg span in MIR dump for tail callMichael Goulet-1/+1
2025-07-31Remove the witness type from coroutine argsMichael Goulet-8/+0
2025-07-24Auto merge of #144389 - scottmcm:no-more-mir-cast-assume, r=davidtwcobors-33/+7
MIR-build: No longer emit assumes in enum-as casting This just uses the `valid_range` from the backend, so it's duplicating the range metadata that now we include on parameters and loads, and thus no longer seems to be useful -- notably there's no codegen test failures from removing it. (Because it's using data from the same source as the backend annotations, it doesn't do anything to mitigate things like rust-lang/rust#144388 where the range in the layout is more permissive than the actual possible discriminants. A variant of this that actually checked the discriminants more specifically might be useful, so could potentially be added in future, but I don't think the *current* checks are actually providing value.) r? mir Randomly turns out that this Fixes https://github.com/rust-lang/rust/issues/121097
2025-07-24MIR-build: No longer emit assumes in enum-as castingScott McMurray-33/+7
This just uses the `valid_range` from the backend, so it's duplicating the range metadata that now we include on parameters and loads.
2025-07-23Give an AllocId to ConstValue::Slice.Camille GILLOT-0/+20
2025-06-25emit `StorageLive` and schedule `StorageDead` for `let`-`else` after matchingdianne-9/+5
2025-05-23yeet `CanonicalVarInfo`lcnr-2/+2
2025-04-22Auto merge of #132833 - est31:stabilize_let_chains, r=fee1-deadbors-15/+21
Stabilize let chains in the 2024 edition # Stabilization report This proposes the stabilization of `let_chains` ([tracking issue], [RFC 2497]) in the [2024 edition] of Rust. [tracking issue]: https://github.com/rust-lang/rust/issues/53667 [RFC 2497]: https://github.com/rust-lang/rfcs/pull/2497 [2024 edition]: https://doc.rust-lang.org/nightly/edition-guide/rust-2024/index.html ## What is being stabilized The ability to `&&`-chain `let` statements inside `if` and `while` is being stabilized, allowing intermixture with boolean expressions. The patterns inside the `let` sub-expressions can be irrefutable or refutable. ```Rust struct FnCall<'a> { fn_name: &'a str, args: Vec<i32>, } fn is_legal_ident(s: &str) -> bool { s.chars() .all(|c| ('a'..='z').contains(&c) || ('A'..='Z').contains(&c)) } impl<'a> FnCall<'a> { fn parse(s: &'a str) -> Option<Self> { if let Some((fn_name, after_name)) = s.split_once("(") && !fn_name.is_empty() && is_legal_ident(fn_name) && let Some((args_str, "")) = after_name.rsplit_once(")") { let args = args_str .split(',') .map(|arg| arg.parse()) .collect::<Result<Vec<_>, _>>(); args.ok().map(|args| FnCall { fn_name, args }) } else { None } } fn exec(&self) -> Option<i32> { let iter = self.args.iter().copied(); match self.fn_name { "sum" => Some(iter.sum()), "max" => iter.max(), "min" => iter.min(), _ => None, } } } fn main() { println!("{:?}", FnCall::parse("sum(1,2,3)").unwrap().exec()); println!("{:?}", FnCall::parse("max(4,5)").unwrap().exec()); } ``` The feature will only be stabilized for the 2024 edition and future editions. Users of past editions will get an error with a hint to update the edition. closes #53667 ## Why 2024 edition? Rust generally tries to ship new features to all editions. So even the oldest editions receive the newest features. However, sometimes a feature requires a breaking change so much that offering the feature without the breaking change makes no sense. This occurs rarely, but has happened in the 2018 edition already with `async` and `await` syntax. It required an edition boundary in order for `async`/`await` to become keywords, and the entire feature foots on those keywords. In the instance of let chains, the issue is the drop order of `if let` chains. If we want `if let` chains to be compatible with `if let`, drop order makes it hard for us to [generate correct MIR]. It would be strange to have different behaviour for `if let ... {}` and `if true && let ... {}`. So it's better to [stay consistent with `if let`]. In edition 2024, [drop order changes] have been introduced to make `if let` temporaries be lived more shortly. These changes also affected `if let` chains. These changes make sense even if you don't take the `if let` chains MIR generation problem into account. But if we want to use them as the solution to the MIR generation problem, we need to restrict let chains to edition 2024 and beyond: for let chains, it's not just a change towards more sensible behaviour, but one required for correct function. [generate correct MIR]: https://github.com/rust-lang/rust/issues/104843 [stay consistent with `if let`]: https://github.com/rust-lang/rust/pull/103293#issuecomment-1293408574 [drop order changes]: https://github.com/rust-lang/rust/issues/124085 ## Introduction considerations As edition 2024 is very new, this stabilization PR only makes it possible to use let chains on 2024 without that feature gate, it doesn't mark that feature gate as stable/removed. I would propose to continue offering the `let_chains` feature (behind a feature gate) for a limited time (maybe 3 months after stabilization?) on older editions to allow nightly users to adopt edition 2024 at their own pace. After that, the feature gate shall be marked as *stabilized*, not removed, and replaced by an error on editions 2021 and below. ## Implementation history * History from before March 14, 2022 can be found in the [original stabilization PR] that was reverted. * https://github.com/rust-lang/rust/pull/94927 * https://github.com/rust-lang/rust/pull/94951 * https://github.com/rust-lang/rust/pull/94974 * https://github.com/rust-lang/rust/pull/95008 * https://github.com/rust-lang/rust/pull/97295 * https://github.com/rust-lang/rust/pull/98633 * https://github.com/rust-lang/rust/pull/99731 * https://github.com/rust-lang/rust/pull/102394 * https://github.com/rust-lang/rust/pull/100526 * https://github.com/rust-lang/rust/pull/100538 * https://github.com/rust-lang/rust/pull/102998 * https://github.com/rust-lang/rust/pull/103405 * https://github.com/rust-lang/rust/pull/103293 * https://github.com/rust-lang/rust/pull/107251 * https://github.com/rust-lang/rust/pull/110568 * https://github.com/rust-lang/rust/pull/115677 * https://github.com/rust-lang/rust/pull/117743 * https://github.com/rust-lang/rust/pull/117770 * https://github.com/rust-lang/rust/pull/118191 * https://github.com/rust-lang/rust/pull/119554 * https://github.com/rust-lang/rust/pull/129394 * https://github.com/rust-lang/rust/pull/132828 * https://github.com/rust-lang/reference/pull/1179 * https://github.com/rust-lang/reference/pull/1251 * https://github.com/rust-lang/rustfmt/pull/5910 [original stabilization PR]: https://github.com/rust-lang/rust/pull/94927 ## Adoption history ### In the compiler * History before March 14, 2022 can be found in the [original stabilization PR]. * https://github.com/rust-lang/rust/pull/115983 * https://github.com/rust-lang/rust/pull/116549 * https://github.com/rust-lang/rust/pull/116688 ### Outside of the compiler * https://github.com/rust-lang/rust-clippy/pull/11750 * [rspack](https://github.com/web-infra-dev/rspack) * [risingwave](https://github.com/risingwavelabs/risingwave) * [dylint](https://github.com/trailofbits/dylint) * [convex-backend](https://github.com/get-convex/convex-backend) * [tikv](https://github.com/tikv/tikv) * [Daft](https://github.com/Eventual-Inc/Daft) * [greptimedb](https://github.com/GreptimeTeam/greptimedb) ## Tests <details> ### Intentional restrictions [`partially-macro-expanded.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/partially-macro-expanded.rs), [`macro-expanded.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs): it is possible to use macros to expand to both the pattern and the expression inside a let chain, but not to the entire `let pat = expr` operand. [`parens.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs): `if (let pat = expr)` is not allowed in chains [`ensure-that-let-else-does-not-interact-with-let-chains.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ensure-that-let-else-does-not-interact-with-let-chains.rs): `let...else` doesn't support chaining. ### Overlap with match guards [`move-guard-if-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs): test for the `use moved value` error working well in match guards. could maybe be extended with let chains that have more than one `let` [`shadowing.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs): shadowing in if let guards works as expected [`ast-validate-guards.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs): let chains in match guards require the match guards feature gate ### Simple cases from the early days PR #88642 has added some tests with very simple usages of `let else`, mostly as regression tests to early bugs. [`then-else-blocks.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/then-else-blocks.rs) [`ast-lowering-does-not-wrap-let-chains.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs) [`issue-90722.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-90722.rs) [`issue-92145.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-92145.rs) ### Drop order/MIR scoping tests [`issue-100276.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/issue-100276.rs): let expressions on RHS aren't terminating scopes [`drop_order.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/drop_order.rs): exhaustive temporary drop order test for various Rust constructs, including let chains [`scope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs): match guard scoping test [`drop-scope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/drop-scope.rs): another match guard scoping test, ensuring that temporaries in if-let guards live for the arm [`drop_order_if_let_rescope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/drop_order_if_let_rescope.rs): if let rescoping on edition 2024, including chains [`mir_let_chains_drop_order.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/mir/mir_let_chains_drop_order.rs): comprehensive drop order test for let chains, distinguishes editions 2021 and 2024. [`issue-99938.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-99938.rs), [`issue-99852.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/mir/issue-99852.rs) both bad MIR ICEs fixed by #102394 ### Linting [`irrefutable-lets.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/irrefutable-lets.rs): trailing and leading irrefutable let patterns get linted for, others don't. The lint is turned off for `else if`. [`issue-121070-let-range.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/lint/issue-121070-let-range.rs): regression test for false positive of the unused parens lint, precedence requires the `()`s here ### Parser: intentional restrictions [`disallowed-positions.rs`](https://github.com/rust-lang/rust/blob/2128d8df0e858edcbe6a0861bac948b88b7fabc3/tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs): `let` in expression context is rejected everywhere except at the top level [`invalid-let-in-a-valid-let-context.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/invalid-let-in-a-valid-let-context.rs): nested `let` is not allowed (let's are no legal expressions just because they are allowed in `if` and `while`). ### Parser: recovery [`issue-103381.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/issues/issue-103381.rs): Graceful recovery of incorrect chaining of `if` and `if let` [`semi-in-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/semi-in-let-chain.rs): Ensure that stray `;`s in let chains give nice errors (`if_chain!` users might be accustomed to `;`s) [`deli-ident-issue-1.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/deli-ident-issue-1.rs), [`brace-in-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/brace-in-let-chain.rs): Ensure that stray unclosed `{`s in let chains give nice errors and hints ### Misc [`conflicting_bindings.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/pattern/usefulness/conflicting_bindings.rs): the conflicting bindings check also works in let chains. Personally, I'd extend it to chains with multiple let's as well. [`let-chains-attr.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/expr/if/attrs/let-chains-attr.rs): attributes work on let chains ### Tangential tests with `#![feature(let_chains)]` [`if-let.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/coverage/branch/if-let.rs): MC/DC coverage tests for let chains [`logical_or_in_conditional.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/mir-opt/building/logical_or_in_conditional.rs): not really about let chains, more about dropping/scoping behaviour of `||` [`stringify.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/macros/stringify.rs): exhaustive test of the `stringify` macro [`expanded-interpolation.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/unpretty/expanded-interpolation.rs), [`expanded-exhaustive.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/unpretty/expanded-exhaustive.rs): Exhaustive test of `-Zunpretty` [`diverges-not.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-0000-never_patterns/diverges-not.rs): Never type, mostly tangential to let chains </details> ## Possible future work * There is proposals to allow `if let Pat(bindings) = expr {}` to be written as `if expr is Pat(bindings) {}` ([RFC 3573]). `if let` chains are a natural extension of the already existing `if let` syntax, and I'd argue orthogonal towards `is` syntax. * https://github.com/rust-lang/lang-team/issues/297 * One could have similar chaining inside `let ... else` statements. There is no proposed RFC for this however, nor is it implemented on nightly. * Match guards have the `if` keyword as well, but on stable Rust, they don't support `let`. The functionality is available via an unstable feature ([`if_let_guard` tracking issue]). Stabilization of let chains affects this feature in so far as match guards containing let chains now only need the `if_let_guard` feature gate be present instead of also the `let_chains` feature (NOTE: this PR doesn't implement this simplification, it's left for future work). [RFC 3573]: https://github.com/rust-lang/rfcs/pull/3573 [`if_let_guard` tracking issue]: https://github.com/rust-lang/rust/issues/51114 ## Open questions / blockers - [ ] bad recovery if you don't put a `let` (I don't think this is a blocker): [#117977](https://github.com/rust-lang/rust/issues/117977) - [x] An instance where a temporary lives shorter than with nested ifs, breaking compilation: [#103476](https://github.com/rust-lang/rust/issues/103476). Personally I don't think this is a blocker either, as it's an edge case. Edit: turns out to not reproduce in edition 2025 any more, due to let rescoping. regression test added in #133093 - [x] One should probably extend the tests for `move-guard-if-let-chain.rs` and `conflicting_bindings.rs` to have chains with multiple let's: done in 133093 - [x] Parsing rejection tests: addressed by https://github.com/rust-lang/rust/pull/132828 - [x] [Style](https://rust-lang.zulipchat.com/#narrow/channel/346005-t-style/topic/let.20chains.20stabilization.20and.20formatting): https://github.com/rust-lang/rust/pull/139456 - [x] https://github.com/rust-lang/rust/issues/86730 explicitly mentions `let_else`. I think we can live with `let pat = expr` not evaluating as `expr` for macro_rules macros, especially given that `let pat = expr` is not a legal expression anywhere except inside `if` and `while`. - [x] Documentation in the reference: https://github.com/rust-lang/reference/pull/1740 - [x] Add chapter to the Rust 2024 [edition guide]: https://github.com/rust-lang/edition-guide/pull/337 - [x] Resolve open questions on desired drop order. [original reference PR]: https://github.com/rust-lang/reference/pull/1179 [edition guide]: https://github.com/rust-lang/edition-guide
2025-04-18Remove let_chains feature gate from even more testsest31-15/+21
2025-04-08Do not optimize out SwitchInt before borrowck, or if Zmir-preserve-ubMichael Goulet-15/+19
2025-03-16Split `visit_primary_bindings` into two variantsZalathar-6/+2
The existing method does some non-obvious extra work to collect user types and build user-type projections, which is specifically needed by `declare_bindings` and not by the other two callers.
2025-03-16Add a mir-opt test that demonstrates user type annotationsZalathar-0/+467
2025-02-05Rollup merge of #135964 - ehuss:cenum_impl_drop_cast, r=Nadrieril许杰友 Jieyou Xu (Joe)-92/+0
Make cenum_impl_drop_cast a hard error This changes the `cenum_impl_drop_cast` lint to be a hard error. This lint has been deny-by-default and warning in dependencies since https://github.com/rust-lang/rust/pull/97652 about 2.5 years ago. Closes https://github.com/rust-lang/rust/issues/73333
2025-01-28Represent the raw pointer for a array length check as a new kind of fake borrowMichael Goulet-3/+3
2025-01-27Reapply "Auto merge of #133734 - scottmcm:lower-indexing-to-ptrmetadata, ↵Michael Goulet-0/+233
r=davidtwco,RalfJung" This reverts commit 122a55bb442bd1995df9cf9b36e6f65ed3ef4a1d.
2025-01-23Make cenum_impl_drop_cast a hard errorEric Huss-92/+0
This changes the `cenum_impl_drop_cast` lint to be a hard error. This lint has been deny-by-default and warning in dependencies since https://github.com/rust-lang/rust/pull/97652 about 2.5 years ago. Closes https://github.com/rust-lang/rust/issues/73333
2025-01-18Revert "Auto merge of #133734 - scottmcm:lower-indexing-to-ptrmetadata, ↵Rémy Rakic-233/+0
r=davidtwco,RalfJung" This reverts commit b57d93d8b9525fa261404b4cd9c0670eeb1264b8, reversing changes made to 0aeaa5eb22180fdf12a8489e63c4daa18da6f236.
2025-01-18Revert "Auto merge of #134330 - scottmcm:no-more-rvalue-len, r=matthewjasper"Rémy Rakic-0/+36
This reverts commit e108481f74ff123ad98a63bd107a18d13035b275, reversing changes made to 303e8bd768526a5812bb1776e798e829ddb7d3ca.
2025-01-10Fix cycle error only occurring with -Zdump-mirOli Scherer-0/+19
2025-01-03turn rustc_box into an intrinsicRalf Jung-13/+3
2024-12-22Delete `Rvalue::Len`Scott McMurray-36/+0
Everything's moved to `PtrMetadata` instead.
2024-12-03Bounds-check with PtrMetadata instead of Len in MIRScott McMurray-0/+233
2024-11-29Doc comment custom MIR debuginfo.Camille GILLOT-3/+38
and add a test for the constant case
2024-10-17bless mir-opt testslcnr-6/+6
2024-09-24be even more precise about "cast" vs "coercion"Lukas Markeffsky-3/+3
2024-09-05Rollup merge of #129664 - ↵Matthias Krüger-1/+1
adetaylor:arbitrary-self-types-pointers-feature-gate, r=wesleywiser Arbitrary self types v2: pointers feature gate. The main `arbitrary_self_types` feature gate will shortly be reused for a new version of arbitrary self types which we are amending per [this RFC](https://github.com/rust-lang/rfcs/blob/master/text/3519-arbitrary-self-types-v2.md). The main amendments are: * _do_ support `self` types which can't safely implement `Deref` * do _not_ support generic `self` types * do _not_ support raw pointers as `self` types. This PR relates to the last of those bullet points: this strips pointer support from the current `arbitrary_self_types` feature. We expect this to cause some amount of breakage for crates using this unstable feature to allow raw pointer self types. If that's the case, we want to know about it, and we want crate authors to know of the upcoming changes. For now, this can be resolved by adding the new `arbitrary_self_types_pointers` feature to such crates. If we determine that use of raw pointers as self types is common, then we may maintain that as an unstable feature even if we come to stabilize the rest of the `arbitrary_self_types` support in future. If we don't hear that this PR is causing breakage, then perhaps we don't need it at all, even behind an unstable feature gate. [Tracking issue](https://github.com/rust-lang/rust/issues/44874) This is [step 4 of the plan outlined here](https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688)
2024-08-31Create opaque definitions in resolver.Camille GILLOT-4/+4
2024-08-27Arbitrary self types v2: pointers feature gate.Adrian Taylor-1/+1
The main `arbitrary_self_types` feature gate will shortly be reused for a new version of arbitrary self types which we are amending per [this RFC](https://github.com/rust-lang/rfcs/blob/master/text/3519-arbitrary-self-types-v2.md). The main amendments are: * _do_ support `self` types which can't safely implement `Deref` * do _not_ support generic `self` types * do _not_ support raw pointers as `self` types. This PR relates to the last of those bullet points: this strips pointer support from the current `arbitrary_self_types` feature. We expect this to cause some amount of breakage for crates using this unstable feature to allow raw pointer self types. If that's the case, we want to know about it, and we want crate authors to know of the upcoming changes. For now, this can be resolved by adding the new `arbitrary_self_types_pointers` feature to such crates. If we determine that use of raw pointers as self types is common, then we may maintain that as an unstable feature even if we come to stabilize the rest of the `arbitrary_self_types` support in future. If we don't hear that this PR is causing breakage, then perhaps we don't need it at all, even behind an unstable feature gate. [Tracking issue](https://github.com/rust-lang/rust/issues/44874) This is [step 4 of the plan outlined here](https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688)
2024-08-18Bless *all* the mir-opt testsScott McMurray-174/+174
2024-08-18Update mir-opt filechecksScott McMurray-3/+3
2024-08-10Update testsNadrieril-31/+11
2024-08-05custom MIR: add support for tail callsRalf Jung-0/+23
2024-07-29Set up false edges in `lower_match_tree`Nadrieril-123/+139
2024-07-09Return the `otherwise_block` instead of passing it as argumentNadrieril-270/+210
This saves a few blocks and matches the common `unpack!` paradigm.
2024-07-09Don't try to save an extra blockNadrieril-173/+201
This is preparation for the next commit.
2024-07-09Auto merge of #127028 - Nadrieril:fix-or-pat-expansion, r=matthewjasperbors-0/+74
Fix regression in the MIR lowering of or-patterns In https://github.com/rust-lang/rust/pull/126553 I made a silly indexing mistake and regressed the MIR lowering of or-patterns. This fixes it. r? `@compiler-errors` because I'd like this to be merged quickly :pray:
2024-06-27Fix expansion of or-patternsNadrieril-10/+8
2024-06-27Add testNadrieril-0/+76
2024-06-22Don't use fake wildcards when we can get the failure block directlyNadrieril-93/+66
This commit too was obtained by repeatedly inlining and simplifying.
2024-06-11Remove DebugWithInfcxMichael Goulet-12/+18
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2025-10-25 23:20:17 +0000