Exhaustively handle expressions in patterns #134228

oli-obk · 2024-12-12T19:56:52Z

We currently have this invariant in HIR that a PatKind::Lit or a PatKind::Range only contains

ExprKind::Lit
ExprKind::UnOp(Neg, ExprKind::Lit)
ExprKind::Path
ExprKind::ConstBlock

So I made PatKind::Lit and PatKind::Range stop containing Expr, and instead created a PatLit type whose kind enum only contains those variants.

The only place code got more complicated was in clippy, as it couldn't share as much anymore with Expr handling

It may be interesting on merging ExprKind::{Path,Lit,ConstBlock} in the future and using the same PatLit type (under a new name).

Then it should also be easier to eliminate any and all UnOp(Neg, Lit) | Lit matching that we have across the compiler. Some day we should fold the negation into the literal itself and just store it on the numeric literals

rustbot · 2024-12-12T19:57:02Z

r? @compiler-errors

rustbot has assigned @compiler-errors.
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

rustbot · 2024-12-12T19:57:04Z

HIR ty lowering was modified

cc @fmease

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in match checking

cc @Nadrieril

rustbot · 2024-12-12T19:58:45Z

HIR ty lowering was modified

cc @fmease

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in match checking

cc @Nadrieril

compiler-errors · 2024-12-12T22:55:55Z

@rustbot author

oli-obk · 2024-12-13T07:49:34Z

I removed the PatKind::Path removal from this PR. I think it should be done, but I'm doing it as a follow-up PR in #134248

@rustbot ready

bors · 2024-12-18T06:29:42Z

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

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

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

compiler/rustc_hir/src/hir.rs

compiler-errors

Other than the naming, which I think we should rename to PatExpr to make it clear that it's the subset of expressions allowed in pats, I think this looks fine.

Rollup merge of rust-lang#134228 - oli-obk:pat-lit-path, r=compiler-errors Exhaustively handle expressions in patterns We currently have this invariant in HIR that a `PatKind::Lit` or a `PatKind::Range` only contains * `ExprKind::Lit` * `ExprKind::UnOp(Neg, ExprKind::Lit)` * `ExprKind::Path` * `ExprKind::ConstBlock` So I made `PatKind::Lit` and `PatKind::Range` stop containing `Expr`, and instead created a `PatLit` type whose `kind` enum only contains those variants. The only place code got more complicated was in clippy, as it couldn't share as much anymore with `Expr` handling It may be interesting on merging `ExprKind::{Path,Lit,ConstBlock}` in the future and using the same `PatLit` type (under a new name). Then it should also be easier to eliminate any and all `UnOp(Neg, Lit) | Lit` matching that we have across the compiler. Some day we should fold the negation into the literal itself and just store it on the numeric literals

Only treat plain literal patterns as short See rust-lang#134228 (comment) and rust-lang#134228 (comment) for context. We never wanted to treat const blocks and paths as short, only plain literals. I don't know how to write a test for this, it.s not clear to me how the short pattern check actually affects the formatting

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`

Rollup merge of rust-lang#135251 - oli-obk:push-lmpyvvyrtplk, r=ytmimi Only treat plain literal patterns as short See rust-lang#134228 (comment) and rust-lang#134228 (comment) for context. We never wanted to treat const blocks and paths as short, only plain literals. I don't know how to write a test for this, it.s not clear to me how the short pattern check actually affects the formatting

Only treat plain literal patterns as short See rust-lang#134228 (comment) and rust-lang#134228 (comment) for context. We never wanted to treat const blocks and paths as short, only plain literals. I don't know how to write a test for this, it.s not clear to me how the short pattern check actually affects the formatting

Rollup merge of rust-lang#135251 - oli-obk:push-lmpyvvyrtplk, r=ytmimi Only treat plain literal patterns as short See rust-lang#134228 (comment) and rust-lang#134228 (comment) for context. We never wanted to treat const blocks and paths as short, only plain literals. I don't know how to write a test for this, it.s not clear to me how the short pattern check actually affects the formatting

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.

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.

…, r=<try> Fix accidentally not emitting overflowing literals lints anymore in patterns This was regressed in rust-lang#134228 (not in beta yet). The issue was that previously we nested `hir::Expr` inside `hir::PatKind::Lit`, so it was linted by the expression code. So now I've set it up for visitors to be able to directly visit literals and get all literals

…eril Reject negative literals for unsigned or char types in pattern ranges and literals It sucks a bit that we have to duplicate the work here (normal expressions just get this for free from the `ExprKind::UnOp(UnOp::Neg, ...)` typeck logic. In rust-lang#134228 I caused ```rust fn main() { match 42_u8 { -10..255 => {}, _ => {} } } ``` to just compile without even a lint. I can't believe we didn't have tests for this Amusingly rust-lang#136302 will also register a delayed bug in `lit_to_const` for this, so we'll have a redundancy if something like this fails again.

…ks, r=compiler-errors Fix accidentally not emitting overflowing literals lints anymore in patterns This was regressed in rust-lang#134228 (not in beta yet). The issue was that previously we nested `hir::Expr` inside `hir::PatKind::Lit`, so it was linted by the expression code. So now I've set it up for visitors to be able to directly visit literals and get all literals

…eril Reject negative literals for unsigned or char types in pattern ranges and literals It sucks a bit that we have to duplicate the work here (normal expressions just get this for free from the `ExprKind::UnOp(UnOp::Neg, ...)` typeck logic. In rust-lang#134228 I caused ```rust fn main() { match 42_u8 { -10..255 => {}, _ => {} } } ``` to just compile without even a lint. I can't believe we didn't have tests for this Amusingly rust-lang#136302 will also register a delayed bug in `lit_to_const` for this, so we'll have a redundancy if something like this fails again.

…ks, r=compiler-errors Fix accidentally not emitting overflowing literals lints anymore in patterns This was regressed in rust-lang#134228 (not in beta yet). The issue was that previously we nested `hir::Expr` inside `hir::PatKind::Lit`, so it was linted by the expression code. So now I've set it up for visitors to be able to directly visit literals and get all literals

…eril Reject negative literals for unsigned or char types in pattern ranges and literals It sucks a bit that we have to duplicate the work here (normal expressions just get this for free from the `ExprKind::UnOp(UnOp::Neg, ...)` typeck logic. In rust-lang#134228 I caused ```rust fn main() { match 42_u8 { -10..255 => {}, _ => {} } } ``` to just compile without even a lint. I can't believe we didn't have tests for this Amusingly rust-lang#136302 will also register a delayed bug in `lit_to_const` for this, so we'll have a redundancy if something like this fails again.

Rollup merge of rust-lang#136304 - oli-obk:push-ymxoklvzrpvx, r=Nadrieril Reject negative literals for unsigned or char types in pattern ranges and literals It sucks a bit that we have to duplicate the work here (normal expressions just get this for free from the `ExprKind::UnOp(UnOp::Neg, ...)` typeck logic. In rust-lang#134228 I caused ```rust fn main() { match 42_u8 { -10..255 => {}, _ => {} } } ``` to just compile without even a lint. I can't believe we didn't have tests for this Amusingly rust-lang#136302 will also register a delayed bug in `lit_to_const` for this, so we'll have a redundancy if something like this fails again.

…ks, r=compiler-errors Fix accidentally not emitting overflowing literals lints anymore in patterns This was regressed in rust-lang#134228 (not in beta yet). The issue was that previously we nested `hir::Expr` inside `hir::PatKind::Lit`, so it was linted by the expression code. So now I've set it up for visitors to be able to directly visit literals and get all literals

Rollup merge of rust-lang#136393 - oli-obk:pattern-type-lit-oflo-checks, r=compiler-errors Fix accidentally not emitting overflowing literals lints anymore in patterns This was regressed in rust-lang#134228 (not in beta yet). The issue was that previously we nested `hir::Expr` inside `hir::PatKind::Lit`, so it was linted by the expression code. So now I've set it up for visitors to be able to directly visit literals and get all literals

…piler-errors Fix accidentally not emitting overflowing literals lints anymore in patterns This was regressed in rust-lang/rust#134228 (not in beta yet). The issue was that previously we nested `hir::Expr` inside `hir::PatKind::Lit`, so it was linted by the expression code. So now I've set it up for visitors to be able to directly visit literals and get all literals

rustbot assigned compiler-errors Dec 12, 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 12, 2024

oli-obk force-pushed the pat-lit-path branch from 763003c to 9af4537 Compare December 12, 2024 19:58

oli-obk force-pushed the pat-lit-path branch from 9af4537 to 42752cc Compare December 12, 2024 20:01

This comment has been minimized.

Sign in to view

oli-obk force-pushed the pat-lit-path branch from 42752cc to 7cee193 Compare December 12, 2024 20:30

This comment has been minimized.

Sign in to view

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 12, 2024

oli-obk force-pushed the pat-lit-path branch from 7cee193 to 37cf874 Compare December 13, 2024 07:49

oli-obk mentioned this pull request Dec 13, 2024

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

Merged

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 13, 2024

This comment has been minimized.

Sign in to view

oli-obk force-pushed the pat-lit-path branch from 37cf874 to 20f5e3f Compare December 13, 2024 09:20

oli-obk force-pushed the pat-lit-path branch from 20f5e3f to c3783c4 Compare December 18, 2024 10:13

compiler-errors reviewed Jan 5, 2025

View reviewed changes

compiler/rustc_hir/src/hir.rs Outdated Show resolved Hide resolved

compiler-errors approved these changes Jan 6, 2025

View reviewed changes

oli-obk force-pushed the pat-lit-path branch from c3783c4 to 295b70f Compare January 7, 2025 08:50

This comment was marked as resolved.

Sign in to view

oli-obk force-pushed the pat-lit-path branch from 295b70f to b27851b Compare January 7, 2025 08:52

rustbot added this to the 1.86.0 milestone Jan 9, 2025

oli-obk deleted the pat-lit-path branch January 9, 2025 10:30

matthiaskrgr mentioned this pull request Jan 9, 2025

ICE: broken mir with inline_const_pat #135306

Closed

This was referenced Jan 30, 2025

Reject negative literals for unsigned or char types in pattern ranges and literals #136304

Merged

Fix accidentally not emitting overflowing literals lints anymore in patterns #136393

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Exhaustively handle expressions in patterns #134228

Exhaustively handle expressions in patterns #134228

oli-obk commented Dec 12, 2024

rustbot commented Dec 12, 2024

rustbot commented Dec 12, 2024

rustbot commented Dec 12, 2024

This comment has been minimized.

This comment has been minimized.

compiler-errors commented Dec 12, 2024

oli-obk commented Dec 13, 2024 •

edited

Loading

This comment has been minimized.

bors commented Dec 18, 2024

bors commented Dec 26, 2024

compiler-errors left a comment

This comment was marked as resolved.

Exhaustively handle expressions in patterns #134228

Exhaustively handle expressions in patterns #134228

Conversation

oli-obk commented Dec 12, 2024

rustbot commented Dec 12, 2024

rustbot commented Dec 12, 2024

rustbot commented Dec 12, 2024

This comment has been minimized.

This comment has been minimized.

compiler-errors commented Dec 12, 2024

oli-obk commented Dec 13, 2024 • edited Loading

This comment has been minimized.

bors commented Dec 18, 2024

bors commented Dec 26, 2024

compiler-errors left a comment

Choose a reason for hiding this comment

This comment was marked as resolved.

oli-obk commented Dec 13, 2024 •

edited

Loading