The pattern-analysis code needs to print patterns, as part of its user-visible
diagnostics. But it never actually tries to print "real" patterns! Instead, it
only ever prints synthetic patterns that it has reconstructed from its own
internal represenations.
We can therefore simultaneously remove two obstacles to changing `thir::Pat`,
by having the pattern-analysis code use its own dedicated type for building
printable patterns, and then making `thir::Pat` not printable at all.
Isolate the diagnostic code that expects `thir::Pat` to be printable
Currently, `thir::Pat` implements `fmt::Display` (and `IntoDiagArg`) directly, for use by a few diagnostics.
That makes it tricky to experiment with alternate representations for THIR patterns, because the patterns currently need to be printable on their own. That immediately rules out possibilities like storing subpatterns as a `PatId` index into a central list (instead of the current directly-owned `Box<Pat>`).
This PR therefore takes an incremental step away from that obstacle, by removing `thir::Pat` from diagnostic structs in `rustc_pattern_analysis`, and hiding the pattern-printing process behind a single public `Pat::to_string` method. Doing so makes it easier to identify and update the code that wants to print patterns, and gives a place to pass in additional context in the future if necessary.
---
I'm currently not sure whether switching over to `PatId` is actually desirable or not, but I think this change makes sense on its own merits, by reducing the coupling between `thir::Pat` and the pattern-analysis error types.
This section of code depends on `rustc_apfloat` rather than our internal
types, so this is one potential ICE that we should be able to melt now.
This also fixes some missing range and match handling in `rustc_middle`.
pattern analysis: add a custom test harness
There are two features of the pattern analysis code that are hard to test: the newly-added pattern complexity limit, and the computation of arm intersections. This PR adds some crate-specific tests for that, including an unmaintainable but pretty macro to help construct patterns.
r? `````@compiler-errors`````
never patterns: suggest `!` patterns on non-exhaustive matches
When a match is non-exhaustive we now suggest never patterns whenever it makes sense.
r? ``@compiler-errors``
pattern analysis: remove `MaybeInfiniteInt::JustAfterMax`
It was inherited from before half-open ranges, but it doesn't pull its weight anymore. We lose a tiny bit of diagnostic precision as can be seen in the test. I'm generally in favor of half-open ranges over explicit `x..=MAX` ranges anyway.
Add stubs in IR and ABI for `f16` and `f128`
This is the very first step toward the changes in https://github.com/rust-lang/rust/pull/114607 and the [`f16` and `f128` RFC](https://rust-lang.github.io/rfcs/3453-f16-and-f128.html). It adds the types to `rustc_type_ir::FloatTy` and `rustc_abi::Primitive`, and just propagates those out as `unimplemented!` stubs where necessary.
These types do not parse yet so there is no feature gate, and it should be okay to use `unimplemented!`.
The next steps will probably be AST support with parsing and the feature gate.
r? `@compiler-errors`
cc `@Nilstrieb` suggested breaking the PR up in https://github.com/rust-lang/rust/pull/120645#issuecomment-1925900572
pattern_analysis: use a plain `Vec` in `DeconstructedPat`
The use of an arena-allocated slice in `DeconstructedPat` dates to when we needed the arena anyway for lifetime reasons. Now that we don't, I'm thinking that if `thir::Pat` can use plain old `Vec`s, maybe so can I.
r? ```@ghost```
pattern_analysis: Gracefully abort on type incompatibility
This leaves the option for a consumer of the crate to return `Err` instead of panicking on type error. rust-analyzer could use that (e.g. https://github.com/rust-lang/rust-analyzer/issues/15808).
Since the only use of `TypeCx::bug` is in `Constructor::is_covered_by`, it is tempting to return `false` instead of `Err()`, but that would cause "non-exhaustive match" false positives.
r? `@compiler-errors`
never patterns: It is correct to lower `!` to `_`.
This is just a comment update but a non-trivial one: it is correct to lower `!` patterns as `_`. The reasoning is that `!` matches all the possible values of the type, since the type is empty. Moreover, we do want to warn that the `Err` is redundant in:
```rust
match x {
!,
Err(!),
}
```
which is consistent with `!` behaving like a wildcard.
I did try to introduce `Constructor::Never` and it ended up needing to behave exactly like `Constructor::Wildcard`.
r? ```@compiler-errors```
