-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
feat: min_exhaustive_patterns
#17853
Conversation
@@ -328,7 +325,7 @@ impl<'db> PatCx for MatchCheckCtx<'db> { | |||
self.exhaustive_patterns | |||
} | |||
fn is_min_exhaustive_patterns_feature_on(&self) -> bool { | |||
self.min_exhaustive_patterns | |||
true |
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.
Should I bump up ra-ap-rustc_pattern_analysis
to latest instead?
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.
There is a PR upstream enabling the in-tree pattern analysis in the rust repo (to prevent us from going out of sync), so these two PRs will likely collide. Might be best if either PR waits on the other (and if we pick this one here first then yes we should bump the dependency here), cc @Nadrieril
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.
Since the rust-lang/rust#128922 is in homu queue, maybe I should wait for it?
_ => true, | ||
} | ||
} | ||
|
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.
This dance is the compressed version of
https://github.com/rust-lang/rust/blob/c9bd03cb724e13cca96ad320733046cbdb16fbbe/compiler/rustc_mir_build/src/thir/cx/expr.rs
and then
https://github.com/rust-lang/rust/blob/c9bd03cb724e13cca96ad320733046cbdb16fbbe/compiler/rustc_mir_build/src/thir/pattern/check_match.rs#L288
@@ -95,8 +93,7 @@ impl<'db> MatchCheckCtx<'db> { | |||
} | |||
} | |||
|
|||
// FIXME: Determine place validity correctly. For now, err on the safe side. | |||
let place_validity = PlaceValidity::MaybeInvalid; | |||
let place_validity = PlaceValidity::from_bool(known_valid_scrutinee.unwrap_or(true)); |
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.
let Ok(_y) = x; | ||
} | ||
"#, | ||
); |
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.
The reason that this test doesn't have a pointer deref case is because the following code;
fn test(ptr: *const Result<i32, !>) {
unsafe {
let Ok(_x) = *ptr;
}
}
is getting a block with no stmts but tail one in here(thus, no diagnostic error),
rust-analyzer/crates/hir-ty/src/diagnostics/expr.rs
Lines 256 to 257 in 0daeb5c
fn validate_block(&mut self, db: &dyn HirDatabase, expr: &Expr) { | |
let Expr::Block { statements, .. } = expr else { return }; |
while the following is getting a block with a single stmt without tail 🤔
fn test(x: Result<i32, &'static !>) {
let Ok(_y) = x;
}
I'll make a more deep inspection and file this as a new issue
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.
is getting a block with no stmts but tail one in here(thus, no diagnostic error),
oh no that sounds very wrong
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.
Yes, it looks very wrong 🤔 I'll check the entire lowering process from AST to hir once I get back home
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.
This is because of #17865
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.
I got into this 😂 rust-lang/rust#129009
No that pr got removed from the queue as it doesn't build, so I guess if
you wanna bump our crates io version first we can swap to in tree in the
rust repo as a follow up after we've synced this back
…On Sun, Aug 11, 2024, 4:55 PM Shoyu Vanilla ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In crates/hir-ty/src/diagnostics/match_check/pat_analysis.rs
<#17853 (comment)>
:
> @@ -328,7 +325,7 @@ impl<'db> PatCx for MatchCheckCtx<'db> {
self.exhaustive_patterns
}
fn is_min_exhaustive_patterns_feature_on(&self) -> bool {
- self.min_exhaustive_patterns
+ true
Since the rust-lang/rust#128922
<rust-lang/rust#128922> is in homu queue, maybe I
should wait for it?
—
Reply to this email directly, view it on GitHub
<#17853 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4VNS23RS47SJL3BM3XIE3ZQ53NLAVCNFSM6AAAAABMKY2JMKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDEMZRHAZTEOBVGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
In either case, I'll continue on this about 20 hours later when I get back from work because it's midnight here 😅 |
No rush |
Well, the latest |
Eh, the autopublish action got frozen by github again due to repo inactivity |
fix: Missing non-exhaustive let diagnostics inside async or unsafe block The reason that this test doesn't have a pointer deref case is because the following code; ```rust fn test(ptr: *const Result<i32, !>) { unsafe { let Ok(_x) = *ptr; } } ``` is getting a block with no stmts but tail one in here(thus, no diagnostic error), https://github.com/rust-lang/rust-analyzer/blob/0daeb5c0b05cfdf2101b0f078c27539099bf38e6/crates/hir-ty/src/diagnostics/expr.rs#L256-L257 while the following is getting a block with a single stmt without tail 🤔 ```rust fn test(x: Result<i32, &'static !>) { let Ok(_y) = x; } ``` I'll make a more deep inspection and file this as a new issue _Originally posted by `@ShoyuVanilla` in #17853 (comment)
☔ The latest upstream changes (presumably #17865) made this pull request unmergeable. Please resolve the merge conflicts. |
a2154da
to
1f25210
Compare
Cargo.toml
Outdated
ra-ap-rustc_parse_format = { version = "0.53.0", default-features = false } | ||
ra-ap-rustc_index = { version = "0.53.0", default-features = false } | ||
ra-ap-rustc_abi = { version = "0.53.0", default-features = false } |
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.
Do bump the other three as well otherwise we get some duplicate transitive dependencies
@bors delegate+ |
✌️ @ShoyuVanilla, you can now approve this pull request! If @Veykril told you to " |
40ef939
to
588fa2c
Compare
@bors r+ |
☀️ Test successful - checks-actions |
fix: Missing non-exhaustive let diagnostics inside async or unsafe block The reason that this test doesn't have a pointer deref case is because the following code; ```rust fn test(ptr: *const Result<i32, !>) { unsafe { let Ok(_x) = *ptr; } } ``` is getting a block with no stmts but tail one in here(thus, no diagnostic error), https://github.com/rust-lang/rust-analyzer/blob/0daeb5c0b05cfdf2101b0f078c27539099bf38e6/crates/hir-ty/src/diagnostics/expr.rs#L256-L257 while the following is getting a block with a single stmt without tail 🤔 ```rust fn test(x: Result<i32, &'static !>) { let Ok(_y) = x; } ``` I'll make a more deep inspection and file this as a new issue _Originally posted by `@ShoyuVanilla` in rust-lang/rust-analyzer#17853 (comment)
Just had time to take a look, looks good to me! Thx for taking the time to do this |
Resolves #17851