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

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::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::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.

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.

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

…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

Only treat plain literal patterns as short

See rust-lang/rust#134228 (comment) and rust-lang/rust#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

This matches the HIR changes in rust-lang#134228, which introduced `PatExpr` to hold the
subset of "expressions" that can appear in a pattern.

This matches the HIR changes in rust-lang#134228, which introduced `PatExpr` to hold the
subset of "expressions" that can appear in a pattern.

This matches the HIR changes in rust-lang#134228, which introduced `PatExpr` to hold the
subset of "expressions" that can appear in a pattern.

…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