-
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
Check pattern refutability on THIR #108504
Conversation
This comment has been minimized.
This comment has been minimized.
808031f
to
9f7d761
Compare
197249f
to
0e1d9e8
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit 0e1d9e82c70ffb828f26152e8b76ed3f8669c6ac with merge 61b7e245cc6359c50ab2968b978381ec8a9716ff... |
☀️ Try build successful - checks-actions |
1 similar comment
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (61b7e245cc6359c50ab2968b978381ec8a9716ff): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
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.
|
r? compiler |
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.
That's some great cleanup, thanks! I especially love how some of the diagnostics got better, like how let None = Some(());
now suggests if let
when it didn't previously.
@@ -61,6 +61,7 @@ fn mir_build(tcx: TyCtxt<'_>, def: ty::WithOptConstParam<LocalDefId>) -> Body<'_ | |||
ty::WithOptConstParam { did, const_param_did: None } => { | |||
tcx.ensure().thir_check_unsafety(did); | |||
drop(tcx.thir_abstract_const(did)); | |||
tcx.ensure().check_match(did); |
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 don't quite understand this change. Is this needed now because the THIR might already be stolen for bodies that required const eval? Why is this not also done for the Some
case, is it just unnecessary or would something break?
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.
check_match
only fetches thir_body(ty::WithOptConstParam::unknown(did))
, so we only need to ensure if we are stealing this exact one.
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.
Makes sense, const args can't contain patterns. Is the loop over all body owners in rustc_interface
still needed then? It seems redundant (except maybe for time passes niceness)
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.
AnonConsts can definitely contain patterns to check. If we want to get rid of the rustc_interface
loop, we'd need to force check_match
in both cases, with a WithOptConstParam
as argument. Like we do for thir_check_unsafety
. I tried to avoid writing all the boilerplate just to remove it once #96840 lands.
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.
Ah right, makes sense. Seems fine to keep it as-is then
fn dep_kind_info(&self, dep_kind: DepKind) -> &DepKindStruct<'tcx> { | ||
&self.query_kinds[dep_kind as usize] | ||
fn dep_kind_info(&self, dk: DepKind) -> &DepKindStruct<'tcx> { | ||
&self.query_kinds[dk as usize] |
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.
Why was this necessary?
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 DepKind::dep_kind
variant. The former version did not handle hygiene correctly, so did not fire in case of macro expansion. The new version just ignores hygiene, so fires. (In that case, it's actually the more correct behaviour.)
Looks good to me, but I'm not familiar enough with the code to approve it. |
Same here. |
You should give that another try, rustbot 😉 |
I had to adapt the handling of the |
@bors r=compiler-errors,Nilstrieb |
☀️ Test successful - checks-actions |
Finished benchmarking commit (0534655): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
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.
CyclesThis benchmark run did not return any relevant results for this metric. |
Marking as triaged since the improvements outweigh the regressions and the regressions are small and in secondary benchmarks. @rustbot label: +perf-regression-triaged |
…er-errors Remove wrong assertion in match checking. This assertions is completely misguided, introduced by rust-lang#108504. The responsible PR is on beta, nominating for backport. Instead of checking that this is not a `&&`, it would make sense to check that neither arms of that `&&` is a `let`. This seems like a lot of code for unclear benefit. r? `@saethlin`
…=eholk Consider lint check attributes on match arms Currently, lint check attributes on match arms have no effect for some lints. This PR makes some lint passes to take those attributes into account. - `LateContextAndPass` for late lint doesn't update `last_node_with_lint_attrs` when it visits match arms. This leads to lint check attributes on match arms taking no effects on late lints that operate on the arms' pattern: ```rust match value { #[deny(non_snake_case)] PAT => {} // `non_snake_case` only warned due to default lint level } ``` To be honest, I'm not sure whether this is intentional or just an oversight. I've dug the implementation history and searched up issues/PRs but couldn't find any discussion on this. - `MatchVisitor` doesn't update its lint level when it visits match arms. This leads to check lint attributes on match arms taking no effect on some lints handled by this visitor, namely: `bindings_with_variant_name` and `irrefutable_let_patterns`. This seems to be a fallout from rust-lang#108504. Before 05082f5, when the visitor operated on HIR rather than THIR, check lint attributes for the said lints were effective. [This playground][play] compiles successfully on current stable (1.69) but fails on current beta and nightly. I wasn't sure where best to place the test for this. Let me know if there's a better place. [play]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=38432b79e535cb175f8f7d6d236d29c3 [play-match]: https://play.rust-lang.org/?version=beta&mode=debug&edition=2021&gist=629aa71b7c84b269beadeba664e2221d
…=eholk Consider lint check attributes on match arms Currently, lint check attributes on match arms have no effect for some lints. This PR makes some lint passes to take those attributes into account. - `LateContextAndPass` for late lint doesn't update `last_node_with_lint_attrs` when it visits match arms. This leads to lint check attributes on match arms taking no effects on late lints that operate on the arms' pattern: ```rust match value { #[deny(non_snake_case)] PAT => {} // `non_snake_case` only warned due to default lint level } ``` To be honest, I'm not sure whether this is intentional or just an oversight. I've dug the implementation history and searched up issues/PRs but couldn't find any discussion on this. - `MatchVisitor` doesn't update its lint level when it visits match arms. This leads to check lint attributes on match arms taking no effect on some lints handled by this visitor, namely: `bindings_with_variant_name` and `irrefutable_let_patterns`. This seems to be a fallout from rust-lang#108504. Before 05082f5, when the visitor operated on HIR rather than THIR, check lint attributes for the said lints were effective. [This playground][play] compiles successfully on current stable (1.69) but fails on current beta and nightly. I wasn't sure where best to place the test for this. Let me know if there's a better place. [play]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=38432b79e535cb175f8f7d6d236d29c3 [play-match]: https://play.rust-lang.org/?version=beta&mode=debug&edition=2021&gist=629aa71b7c84b269beadeba664e2221d
The current
check_match
query is based on HIR, but partially re-lowers HIR into THIR.This PR proposed to use the results of the
thir_body
query to check matches, instead of re-building THIR.Most of the diagnostic changes are spans getting shorter, or commas/semicolons not getting removed.
This PR degrades the diagnostic for confusing constants in patterns (
let A = foo()
whereA
resolves to aconst A
somewhere): it does not point ot the definition ofconst A
any more.