| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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`
|
|
Co-authored-by: Boxy <rust@boxyuwu.dev>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
add a scope for `if let` guard temporaries and bindings
This fixes my concern with `if let` guard drop order, namely that the guard's bindings and temporaries were being dropped after their arm's pattern's bindings, instead of before (https://github.com/rust-lang/rust/pull/141295#issuecomment-2968975596). The guard's bindings and temporaries now live in a new scope, which extends until (but not past) the end of the arm, guaranteeing they're dropped before the arm's pattern's bindings.
This only introduces a new scope for match arms with guards. Perf results (https://github.com/rust-lang/rust/pull/143376#issuecomment-3034922617) seemed to indicate there wasn't a significant hit to introduce a new scope on all match arms, but guard patterns (rust-lang/rust#129967) will likely benefit from only adding new scopes when necessary (with some patterns requiring multiple nested scopes).
Tracking issue for `if_let_guard`: rust-lang/rust#51114
Tests are adapted from examples by `@traviscross,` `@est31,` and myself on rust-lang/rust#141295.
|
|
coverage: Remove all unstable support for MC/DC instrumentation
Preliminary support for a partial implementation of “Modified Condition/Decision Coverage” instrumentation was added behind the unstable flag `-Zcoverage-options=mcdc` in 2024. These are the most substantial PRs involved:
- rust-lang/rust#123409
- rust-lang/rust#126733
At the time, I accepted these PRs with relatively modest scrutiny, because I did not want to stand in the way of independent work on MC/DC instrumentation. My hope was that ongoing work by interested contributors would lead to the code becoming clearer and more maintainable over time.
---
However, that MC/DC code has proven itself to be a major burden on overall maintenance of coverage instrumentation, and a major obstacle to other planned improvements, such as internal changes needed for proper support of macro expansion regions.
I have also become reluctant to accept any further MC/DC-related changes that would increase this burden.
That tension has resulted in an unhappy impasse. On one hand, the present MC/DC implementation is not yet complete, and shows little sign of being complete at an acceptable level of code quality in the foreseeable future. On the other hand, the continued existence of this partial MC/DC implementation is imposing serious maintenance burdens on every other aspect of coverage instrumentation, and is preventing some of the very improvements that would make it easier to accept expanded MC/DC support in the future.
While I know this will be disappointing to some, I think the healthy way forward is accept that I made the wrong call in accepting the current implementation, and to remove it entirely from the compiler.
|
|
|
|
This ensures `if let` guard temporaries and bindings are dropped before
the match arm's pattern's bindings.
|
|
r=Nadrieril,traviscross
lower pattern bindings in the order they're written and base drop order on primary bindings' order
To fix rust-lang/rust#142163, this PR does two things:
- Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings).
- Lowers pattern bindings in the order they're written (still treating the right-hand side of a ``@`` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](https://github.com/rust-lang/rust/blob/2a023bf80a6fbd6a06d5460a34eb247b986286ed/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from rust-lang/rust#121716.
My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives:
- We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es.
- I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here.
- For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched.
This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference.
This will conflict with rust-lang/rust#143376 and probably also rust-lang/rust#143028, so they shouldn't be merged at the same time.
r? `@matthewjasper` or `@Nadrieril`
|
|
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
|
|
|
|
|
|
This avoids scheduling drops and immediately unscheduling them. Drops
for guard bindings/temporaries are still scheduled and unscheduled as
before.
|
|
|
|
fixes issue 143203
|
|
Avoid introducing a large number of changes when adding optional initialization fields.
|
|
|
|
Co-authored-by: Folkert de Vries <folkert@folkertdev.nl>
|
|
|
|
This allows deref patterns to move out of boxes.
Implementation-wise, I've opted to put the information of whether a
deref pattern uses a built-in deref or a method call in the THIR. It'd
be a bit less code to check `.is_box()` everywhere, but I think this way
feels more robust (and we don't have a `mutability` field in the THIR
that we ignore when the smart pointer's a box). I'm not sure about the
naming (or using `ByRef`), though.
|
|
Specifically, this allows string literal patterns to be used where a
`str` is expected when `deref_patterns` is enabled.
|
|
|
|
Overhaul `AssocItem`
`AssocItem` has multiple fields that only make sense some of the time. E.g. the `name` can be empty if it's an RPITIT associated type. It's clearer and less error prone if these fields are moved to the relevant `kind` variants.
r? ``@fee1-dead``
|
|
Allow const patterns of matches to contain pattern types
Trying to pattern match on a type containing a pattern type will currently fail with an ICE
```rust
error: internal compiler error: compiler/rustc_mir_build/src/builder/matches/test.rs:459:18: invalid type for non-scalar compare: (u32) is 1..
--> src/main.rs:22:5
|
22 | TWO => {}
| ^^^
```
because the compiler tries to generate a MIR `BinOp(Eq)` operation on a pattern type, which is not supported. While we could support that, there are side effects of allowing this (none that would compile, but the compiler would simultaneously think it could `==` pattern types and that it could not because `PartialEq` is not implemented. So instead I change the logic for pattern matching to transmute pattern types to their base type before comparing.
r? ```@BoxyUwU```
cc #123646 ```@scottmcm``` ```@joshtriplett```
|
|
|
|
`hir::AssocItem` currently has a boolean `fn_has_self_parameter` field,
which is misplaced, because it's only relevant for associated fns, not
for associated consts or types. This commit moves it (and renames it) to
the `AssocKind::Fn` variant, where it belongs.
This requires introducing a new C-style enum, `AssocTag`, which is like
`AssocKind` but without the fields. This is because `AssocKind` values
are passed to various functions like `find_by_ident_and_kind` to
indicate what kind of associated item should be searched for, and having
to specify `has_self` isn't relevant there.
New methods:
- Predicates `AssocItem::is_fn` and `AssocItem::is_method`.
- `AssocItem::as_tag` which converts `AssocItem::kind` to `AssocTag`.
Removed `find_by_name_and_kinds`, which is unused.
`AssocItem::descr` can now distinguish between methods and associated
functions, which slightly improves some error messages.
|
|
Simplify `thir::PatKind::ExpandedConstant`
I made it a bit less ad-hoc. In particular, I removed `is_inline: bool` that was just caching the output of `tcx.def_kind(def_id)`. This makes inline consts a tiny bit less special in patterns.
r? `@oli-obk`
cc `@Zalathar`
|
|
|
|
|
|
"Missing" patterns are possible in bare fn types (`fn f(u32)`) and
similar places. Currently these are represented in the AST with
`ast::PatKind::Ident` with no `by_ref`, no `mut`, an empty ident, and no
sub-pattern. This flows through to `{hir,thir}::PatKind::Binding` for
HIR and THIR.
This is a bit nasty. It's very non-obvious, and easy to forget to check
for the exceptional empty identifier case.
This commit adds a new variant, `PatKind::Missing`, to do it properly.
The process I followed:
- Add a `Missing` variant to `{ast,hir,thir}::PatKind`.
- Chang `parse_param_general` to produce `ast::PatKind::Missing`
instead of `ast::PatKind::Missing`.
- Look through `kw::Empty` occurrences to find functions where an
existing empty ident check needs replacing with a `PatKind::Missing`
check: `print_param`, `check_trait_item`, `is_named_param`.
- Add a `PatKind::Missing => unreachable!(),` arm to every exhaustive
match identified by the compiler.
- Find which arms are actually reachable by running the test suite,
changing them to something appropriate, usually by looking at what
would happen to a `PatKind::Ident`/`PatKind::Binding` with no ref, no
`mut`, an empty ident, and no subpattern.
Quite a few of the `unreachable!()` arms were never reached. This makes
sense because `PatKind::Missing` can't happen in every pattern, only
in places like bare fn tys and trait fn decls.
I also tried an alternative approach: modifying `ast::Param::pat` to
hold an `Option<P<Pat>>` instead of a `P<Pat>`, but that quickly turned
into a very large and painful change. Adding `PatKind::Missing` is much
easier.
|
|
Revert "Make MatchPairTree::place non-optional"
Reverts a part of #137875. Fixes #138958.
cc `@Zalathar`
|
|
Don't produce debug information for compiler-introduced-vars when desugaring assignments.
An assignment such as
(a, b) = (b, c);
desugars to the HIR
{ let (lhs, lhs) = (b, c); a = lhs; b = lhs; };
The repeated `lhs` leads to multiple Locals assigned to the same DILocalVariable. Rather than attempting to fix that, get rid of the debug info for these bindings that don't even exist in the program to begin with.
Fixes #138198
r? `@jieyouxu`
|
|
|
|
This reverts commit e3e74bc89a958e36c658fa809d98b4dd66d53cf8.
The comment that was used to justify the change was outdated.
|
|
Since array and slice constants are now lowered to array and slice
patterns, `non_scalar_compare` was only called for string comparisons.
This specializes it to strings, renames it, and removes the unused
array-unsizing logic.
This also updates some outdated doc comments.
|
|
assignments.
An assignment such as
(a, b) = (b, c);
desugars to the HIR
{ let (lhs, lhs) = (b, c); a = lhs; b = lhs; };
The repeated `lhs` leads to multiple Locals assigned to the same DILocalVariable. Rather than
attempting to fix that, get rid of the debug info for these bindings that don't even exist
in the program to begin with.
Fixes #138198
|
|
mir_build: consider privacy when checking for irrefutable patterns
This PR fixes #137999.
Note that, since this makes the compiler reject code that was previously accepted, it will probably need a crater run.
I include a commit that factors out a common code pattern into a helper function, purely because the fact that this was repeated all over the place was bothering me. Let me know if I should split that into a separate PR instead.
|
|
|
|
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.
|
|
This avoids the need to unwrap an option after ensuring that it is some.
|
|
|
|
A check for `#[non_exhaustive]` is often done in combination with
checking whether the type is local to the crate, in a variety of ways.
Create a helper method and standardize on it as the way to check for
this.
|
|
As the invariant indicated, this place could only be none for
`TestCase::Irrefutable` nodes, which no longer exist.
|
|
What remained of this simplification process has been integrated into
construction of the match-pair trees.
|
|
|
