Line 171 introduced `pt_1, .., pt_n` and `qt` as variable names, but
line 172 incorrectly used `tp_1, .., tp_n, tq`. This commit fixes the
inconsistency to use the correct variable names throughout.
This was done in #145740 and #145947. It is causing problems for people
using r-a on anything that uses the rustc-dev rustup package, e.g. Miri,
clippy.
This repository has lots of submodules and subtrees and various
different projects are carved out of pieces of it. It seems like
`[workspace.dependencies]` will just be more trouble than it's worth.
match exhaustiveness diagnostics: show a trailing comma on singleton tuple consructors in witness patterns (and clean up a little)
Constructor patterns of type `(T,)` are written `(pat,)`, not `(pat)`. However, exhaustiveness/usefulness diagnostics would print them as `(pat)` when e.g. providing a witness of non-exhaustiveness and suggesting adding arms to make matches exhaustive; this would result in an error when applied.
rust-analyzer already prints the trailing comma, so it doesn't need changing.
This also includes some cleanup in the second commit, with justification in the commit message.
By construction, `subpatterns` contains all fields in order. Witness
patterns are constructed with all fields in order by
`WitnessPat::wild_from_ctor` and `WitnessStack::apply_constructor`, and
the order is preserved at `write_struct_like`'s call-site in
`print_witness_pat`. It's thus no longer necessary to go looking for
fields or handle missing fields.
In rustc_pattern_analysis, put `true` witnesses before `false` witnesses
In rustc it doesn't really matter what the order of the witnesses is, but I'm planning to use the witnesses for implementing the "add missing match arms" assist in rust-analyzer, and there `true` before `false` is the natural order (like `Some` before `None`), and also what the current assist does.
The current order doesn't seem to be intentional; the code was created when bool ctors became their own thing, not just int ctors, but for integer, 0 before 1 is indeed the natural order.
r? `@Nadrieril`
In rustc it doesn't really matter what the order of the witnesses is, but I'm planning to use the witnesses for implementing the "add missing match arms" assist in rust-analyzer, and there `true` before `false` is the natural order (like `Some` before `None`), and also what the current assist does.
The current order doesn't seem to be intentional; the code was created when bool ctors became their own thing, not just int ctors, but for integer, 0 before 1 is indeed the natural order.
pattern_analysis: add option to get a full set of witnesses
This adds an option to the rustc_pattern_analysis machinery to have it report a complete set of patterns when a match is non-exhaustive (by default we only guarantee to report _some_ missing patterns). This is for use in rust-analyzer.
Leaving as draft until I'm sure this is what r-a needs.
r? ghost
This removes special-casing of boxes from `rustc_pattern_analysis`, as a
first step in replacing `box_patterns` with `deref_patterns`.
Incidentally, it fixes a bug caused by box patterns being represented as
structs rather than pointers, where `exhaustive_patterns` could generate
spurious `unreachable_patterns` lints on arms required for
exhaustiveness; following the lint's advice would result in an error.
Without adding proper support for mixed exhaustiveness, mixing deref
patterns with normal constructors would either violate
`ConstructorSet::split`'s invariant 4 or 7. We'd either be ignoring rows
with normal constructors or we'd have problems in unspecialization from
non-disjoint constructors. Checking mixed exhaustivenss similarly to how
unions are currently checked should work, but the diagnostics for unions
are confusing. Since mixing deref patterns with normal constructors is
pretty niche (currently it only makes sense for `Cow`), emitting an
error lets us avoid committing to supporting mixed exhaustiveness
without a good answer for the diagnostics.
This does not yet handle the case of mixed deref patterns with normal
constructors; it'll ICE in `Constructor::is_covered_by`. That'll be
fixed in a later commit.
This will allow us to eagerly translate messages on a top-level
diagnostic, such as a `LintDiagnostic`. As a bonus, we can remove the
awkward closure passed into Subdiagnostic and make better use of
`Into`.
