Previously, we threw away the `Span` associated with a definition's
identifier when we encoded crate metadata, causing us to lose location
and hygiene information.
We now store the identifier's `Span` in the crate metadata.
When we decode items from the metadata, we combine
the name and span back into an `Ident`.
This improves the output of several tests, which previously had messages
suppressed due to dummy spans.
This is a prerequisite for #68686, since throwing away a `Span` means
that we lose hygiene information.
This uses the exact same code path that would be used for
`match x { _ if false => {} }`, since in both cases the resulting matrix
is empty. Since we think the behaviour in that case is ok, then we can
remove the special case and use the default code path.
It is used in the case where a variable-length slice pattern is used to
match on an array of known size. This allows considering only those
entries in the array that are captured by one of the patterns.
As a side-effect, diagnostics improve a bit for those cases.
The previous behaviour ignored slice lengths above a certain length
because it could not do otherwise. We now have VarLenSlice however, that
can represent the ignored lengths to make the algorithm more consistent.
This does not change the correctness of the algorithm, but makes it
easier to reason about.
As a nice side-effect, exhaustiveness errors have improved: they now
capture all missing lengths instead of only the shortest.
This improves error messages by indicating when slices above a certain
lengths have not been matched. Previously, we would only report examples
of such lengths, but of course never all of them.
Those annotation are silently ignored rather than begin validated
against compiler output. Update them before validation is enabled,
to avoid test failures.
I took most tests that were testing only for match exhaustiveness,
pattern refutability or match arm reachability, and put them in
the same test folder.
