-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exhaustiveness: keep the original thir::Pat
around
#119233
Conversation
r? @TaKO8Ki (rustbot has picked a reviewer for you, use r? to override) |
Some changes occurred in cc @BoxyUwU |
d945d2a
to
e579fc6
Compare
This comment was marked as outdated.
This comment was marked as outdated.
r? compiler-errors I'll review this maybe tomorrow morning |
This comment was marked as outdated.
This comment was marked as outdated.
e579fc6
to
4a88c2b
Compare
This comment was marked as outdated.
This comment was marked as outdated.
4a88c2b
to
87e93f6
Compare
WIP: Lint small gaps between ranges In the discussion to stabilize exclusive range patterns (rust-lang#37854), it has often come up that they're likely to cause off-by-one mistakes. We already have the `overlapping_range_endpoints` lint, so I [proposed](rust-lang#37854 (comment)) a lint to catch the complementary mistake. This PR adds a new `small_gaps_between_ranges` lint that catches likely off-by-one errors with range patterns. Here's the idea (see the test file for more examples): ```rust match x { 0..10 => ..., // WARN: this range doesn't match `10_u8` because `..` is a non-inclusive range 11..20 => ..., // this seems to continue range `0_u8..10_u8`, but `10_u8` isn't matched by either of them _ => ..., } // help: use an inclusive range instead: `0_u8..=10_u8` ``` More precisely: for any exclusive range `lo..hi`, if `hi+1` is matched by another range but `hi` isn't, we suggest writing an inclusive range `lo..=hi` instead. We don't lint `lo..T::MAX` but we could. WARNING: the first 3 commits come from rust-lang#119233, ignore those. r? ghost
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me, but I'm a bit confused why 'p
and 'thir
are different... do you mind double-checking that that's necessary?
@@ -453,14 +453,14 @@ pub enum UnusedUnsafeEnclosing { | |||
}, | |||
} | |||
|
|||
pub(crate) struct NonExhaustivePatternsTypeNotEmpty<'p, 'tcx, 'm> { | |||
pub cx: &'m RustcMatchCheckCtxt<'p, 'tcx>, | |||
pub(crate) struct NonExhaustivePatternsTypeNotEmpty<'p, 'thir, 'tcx, 'm> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When is 'p
shorter than 'thir
? Isn't 'p
the lifetime of the "pattern"? Shouldn't that be from the THIR anyways?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hehe, my solution to lifetime problems tends to be "add more lifetimes".
'thir
is the lifetime of thir::Pat
patterns we indeed get from the thir. 'p
is the lifetime of the DeconstructedPat
s we allocate in the arena.
I agree that it feels like 'p
should be all we need, lemme try that again now that I understand the situation better
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If 'thir
and 'p
are both covariant, then they should be able to be unified. But maybe not -- I guess give it a shot but r=me if it doesn't end up working out.
@rustbot author |
I was able to cherry-pick this PR quite easily onto #119307, so I would prefer if we land my PR first. It's going to be a nightmare to have to remove See master...compiler-errors:rust:thir-too for proof :) |
☔ The latest upstream changes (presumably #119146) made this pull request unmergeable. Please resolve the merge conflicts. |
87e93f6
to
b931cf5
Compare
Rebased this onto your #119307, indeed that was very straightforward |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me when other pr lands
…adrieril Clean up some lifetimes in `rustc_pattern_analysis` This PR removes some redundant lifetimes. I figured out that we were shortening the lifetime of an arena-allocated `&'p DeconstructedPat<'p>` to `'a DeconstructedPat<'p>`, which forced us to carry both lifetimes when we could otherwise carry just one. This PR also removes and elides some unnecessary lifetimes. I also cherry-picked 0292eb9, and then simplified more lifetimes in `MatchVisitor`, which should make rust-lang#119233 a very simple PR! r? Nadrieril
Rollup merge of rust-lang#119307 - compiler-errors:pat-lifetimes, r=Nadrieril Clean up some lifetimes in `rustc_pattern_analysis` This PR removes some redundant lifetimes. I figured out that we were shortening the lifetime of an arena-allocated `&'p DeconstructedPat<'p>` to `'a DeconstructedPat<'p>`, which forced us to carry both lifetimes when we could otherwise carry just one. This PR also removes and elides some unnecessary lifetimes. I also cherry-picked 0292eb9, and then simplified more lifetimes in `MatchVisitor`, which should make rust-lang#119233 a very simple PR! r? Nadrieril
b931cf5
to
fc0be3c
Compare
@bors r=compiler-errors |
…ompiler-errors Exhaustiveness: keep the original `thir::Pat` around This PR makes it possible for exhaustiveness to look at the original `thir::Pat`, which I'll need at least for the [`small_gaps`](rust-lang#118879) lint (without that we can't distinguish inclusive and exclusive ranges within exhaustiveness). This PR is almost entirely lifetime-wrangling.
💔 Test failed - checks-actions |
@bors retry |
☀️ Test successful - checks-actions |
Finished benchmarking commit (9da4432): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 671.494s -> 670.712s (-0.12%) |
This PR makes it possible for exhaustiveness to look at the original
thir::Pat
, which I'll need at least for thesmall_gaps
lint (without that we can't distinguish inclusive and exclusive ranges within exhaustiveness). This PR is almost entirely lifetime-wrangling.