Merge `PatKind::Path` into `PatKind::Expr` #134248

oli-obk · 2024-12-13T07:52:26Z

Follow-up to #134228

We always had a duplication where Paths could be represented as PatKind::Path or PatKind::Lit(ExprKind::Path). We had to handle both everywhere, and still do after #134228, so I'm removing it now.

rustbot · 2024-12-13T07:52:37Z

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

…ler-errors Forbid overwriting types in typeck While trying to figure out some type setting logic in rust-lang#134248 I realized that we sometimes set a type twice. While hopefully that would have been the same type, we didn't ensure that at all and just silently accepted it. So now we reject setting it twice, unless errors are happening, then we don't care. Best reviewed commit by commit. No behaviour change is intended.

Rollup merge of rust-lang#134474 - oli-obk:push-yomnkntvzlxw, r=compiler-errors Forbid overwriting types in typeck While trying to figure out some type setting logic in rust-lang#134248 I realized that we sometimes set a type twice. While hopefully that would have been the same type, we didn't ensure that at all and just silently accepted it. So now we reject setting it twice, unless errors are happening, then we don't care. Best reviewed commit by commit. No behaviour change is intended.

Forbid overwriting types in typeck While trying to figure out some type setting logic in rust-lang/rust#134248 I realized that we sometimes set a type twice. While hopefully that would have been the same type, we didn't ensure that at all and just silently accepted it. So now we reject setting it twice, unless errors are happening, then we don't care. Best reviewed commit by commit. No behaviour change is intended.

bors · 2024-12-26T21:52:41Z

☔ The latest upstream changes (presumably #134788) made this pull request unmergeable. Please resolve the merge conflicts.

oli-obk · 2025-01-07T10:28:56Z

@bors try @rust-timer queue

Merge `PatKind::Path` into `PatKind::Lit` Follow-up to rust-lang#134228 We always had a duplication where `Path`s could be represented as `PatKind::Path` or `PatKind::Lit(ExprKind::Path)`. We had to handle both everywhere, and still do after rust-lang#134228, so I'm removing it now. subsequently we can also nuke `visit_pattern_type_pattern`

bors · 2025-01-07T10:30:09Z

⌛ Trying commit 2269e1f with merge 801e8e4...

oli-obk · 2025-01-20T14:07:58Z

😅 finally. Ready for review as I have nothing more to add on the code side. Best reviewed commit by commit

BoxyUwU · 2025-01-23T09:04:25Z

compiler/rustc_hir/src/intravisit.rs

+        PatKind::Expr(ref expression) => {
+            try_visit!(walk_pat_expr(visitor, pattern.hir_id, pattern.span, expression))
+        }


So this is kind of sketchy. It means that overriding visit_pat_expr wont' actually visit any PatKind::Expr. I haven't looked to see if any existing hir visitors would be incorrect now but at the very least it seems like unexpected behaviour.

It also seems like to some extent jankyness around hir visitors and patterns is pre-existing, we store PatExpr in PatKind::Range which means that overriding the visit_pat function won't actually visit the patterns in range patterns. Again I don't really know if there's any existing hir visitors which are buggy because of this but it feels unexpected and like it could cause issues.

If it's possible to keep PatKind::Expr as containing a PatExpr for now that would mean that this PR wouldn't make anything worse here. I could imagine that potentially having performance implications though from now having more nodes in the HIR, more HirIds and generally Pat being larger as path exprs now go through a layer of indirection through a PatExpr.

Can probably figure out other solutions if that doesn't work out perf wise, though if that doesn't work out it's probably worth figuring out how to also make visit_pat visit all patterns as it wouldn't surprise me if they wind up being similar solutions.

visit the patterns in range patterns

there are no patterns within range patterns. you can't do a..5

Right it's a PatExpr but that's still a pattern no? Just because we don't support all pattern syntax there doesn't make it not a pattern 🤔

edit: Maybe that's just not a good intuition and it's fine for visit_pat to not visit that stuff though, the important thing is the visit_pat_expr stuff I think since its a new change

141c3ba#diff-ffa196a0614fce5117ac525b8da3cbf210e21efa6f743b2ec2b7eb3d8ea38a76R331-R333 I assume this change is a manifestation of the fact that by storing an PatExprKind, visitors which are doing something "obviously right" overriding visit_pat_expr now no longer actually visit all pat exprs

this definitely makes me feel like this is something that could be hit in practice so should probably be worked around somehow

oli-obk · 2025-01-23T09:50:09Z

@bors try @rust-timer queue

Merge `PatKind::Path` into `PatKind::Expr` Follow-up to rust-lang#134228 We always had a duplication where `Path`s could be represented as `PatKind::Path` or `PatKind::Lit(ExprKind::Path)`. We had to handle both everywhere, and still do after rust-lang#134228, so I'm removing it now.

bors · 2025-01-23T09:51:24Z

⌛ Trying commit fd47152 with merge 78fe09469938ee57fbc1e1dc8e20855ef0609ae0...

oli-obk · 2025-01-23T09:52:25Z

compiler/rustc_ast_lowering/src/pat.rs

+                        let expr = hir::PatExpr { hir_id: pat_hir_id, span, kind };
+                        let expr = self.arena.alloc(expr);
+                        return hir::Pat {
+                            hir_id: self.next_id(),
+                            kind: hir::PatKind::Expr(expr),
+                            span,
+                            default_binding_modes: true,
+                        };


Fishy HirId swap, but I can't remember why this is the right soluation. If I do it differently we end up not being able to handle assoc consts anymore

bors · 2025-01-23T11:32:14Z

💔 Test failed - checks-actions

oli-obk · 2025-01-23T13:37:41Z

@bors try @rust-timer queue

bors · 2025-01-23T13:38:56Z

⌛ Trying commit dbf867b with merge a5bd41a...

Merge `PatKind::Path` into `PatKind::Expr` Follow-up to rust-lang#134228 We always had a duplication where `Path`s could be represented as `PatKind::Path` or `PatKind::Lit(ExprKind::Path)`. We had to handle both everywhere, and still do after rust-lang#134228, so I'm removing it now.

bors · 2025-01-23T15:49:30Z

☀️ Try build successful - checks-actions
Build commit: a5bd41a (a5bd41a49f2a00ea177a196fca62d6568cc9d37b)

rust-timer · 2025-01-23T17:05:46Z

Finished benchmarking commit (a5bd41a): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking 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 @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.1%, 0.4%]	8
Regressions ❌ (secondary)	0.3%	[0.1%, 0.5%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.1%, 0.4%]	8

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 778.767s -> 774.185s (-0.59%)
Artifact size: 325.93 MiB -> 325.92 MiB (-0.00%)

oli-obk · 2025-01-23T17:11:49Z

No diffs in query executions, so it's all about incremental caching being more expensive due to the extra node, which is unavoidable, but also very small. We can always revisit in the future, but more robust code trumps perf for now.

rustbot assigned BoxyUwU Dec 13, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Dec 13, 2024

oli-obk mentioned this pull request Dec 13, 2024

Exhaustively handle expressions in patterns #134228

Merged