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.
Validate error patterns and error annotation in ui tests when present
Previously, when compilation succeeded, neither error patterns nor error
annotation would be validated. Additionally, when compilation failed,
only error patterns would be validated if both error patterns and error
annotation were present.
Now both error patterns and error annotation are validated when present,
regardless of compilation status. Furthermore, for test that should run,
the error patterns are matched against executable output, which is what
some of tests already expect to happen, and when #65506 is merged even
more ui tests will.
Fixes#56277
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.
Point at the span for the definition of ADTs internal to the current
crate.
Look at the leading char of the ident to determine whether we're
expecting a likely fn or any of a fn, a tuple struct or a tuple variant.
Turn fn `add_typo_suggestion` into a `Resolver` method.
