The key can only be an Expression but was unneedingly wrapped in
a ConstantPattern. Since the shared type analysis only handles
map pattern keys as expressions, the expected properties of
ConstantPattern were not set. Amongst these were the static type
of the key expression, which is know passed directly to the
handleMapPatternEntry method.
Change-Id: I705fc655e440d534ccc442c9c1359c377955b3b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288282
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This turns on the flags for these two language features and makes
them generally accessible.
Doing so causes a number of tests to fail, but the failures are
approved and there are filed issues for them. Most of the
failures are minor or only affect code using the new language
features.
This CL:
- Enables the features in experimental_features.yaml.
- Re-generates all of the various files generated from that.
- Makes some analyzer and front end changes that this CL
inherited from Paul's original CL flipping all of the 3.0
feature flags. I don't know what these changes are about, but
I assume they are necessary.
- Pins a couple of tests to 2.19 since they deliberately test
behavior that is specific to 2.19. (For most test changes, I've
landed them separately, but there are a couple of stragglers
in this CL.)
This doesn't enable "class-modifiers" or "sealed-types" and doesn't
include the core lib changes related to those.
TEST=On bots
Change-Id: Id387753772286a958e20a3589a6e983995f2e4a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286344
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Includes several updates to tests that needed to land with this flip, as well as some other tests that needed to be updated and could land separately, but are being included here to expedite things.
Removes some unnecessary experimental release versions, as well as bringing up to date the generated files, which were previously out of sync with the yaml file.
TEST=bots
Change-Id: I71a86d7a86190069b504bd27d687f62b97a7251e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/285080
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This adds improved support for map patterns. A new [Restriction]
class replaces the [TypeBasedStaticType.identity] properties and
allows not only for unique values as subtypes but also subsets of
values as subtypes. For map pattern the subsets are defined by
a [MapTypeIdentity] based on the type arguments of the map pattern,
its constant key values and whether it has a rest pattern.
Change-Id: I32b95f519cc161975af17ea82beacbc27ad5bbe1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287464
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This reverts commit 4f8333e80e.
Reason for revert: causes breakages in google3
Original change's description:
> Add more `interface` and `final` modifiers to `dart:core`.
>
> Make intent explicit for classes which are intended as interfaces,
> or which are not intended to be subclassed.
>
> Mainly classes which are pure interfaces are marked as such,
> and platform-specific classes not intended for subclassing
> are made `final`.
>
> The `final` classes includes `BigInt`, which is written to assume
> that arguments inherit its private members
> (it runs `_ensureSystemBigInt` on arguments).
>
> It also includes the `Expando`, `WeakReference` and `Finalizer` classes,
> which are just intended as stand-alone implementation classes for accessing
> platform-specific functionality.
>
> Change-Id: Ib770c265edff127a289a67fe72d15b9ff0499407
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287180
> Reviewed-by: Stephen Adams <sra@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
> Reviewed-by: Aske Simon Christensen <askesc@google.com>
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
Change-Id: I94ff95f72410a4e1ae80744971c4c920fecc1493
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287760
Reviewed-by: Martin Kustermann <kustermann@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Oleh Prypin <oprypin@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Make intent explicit for classes which are intended as interfaces,
or which are not intended to be subclassed.
Mainly classes which are pure interfaces are marked as such,
and platform-specific classes not intended for subclassing
are made `final`.
The `final` classes includes `BigInt`, which is written to assume
that arguments inherit its private members
(it runs `_ensureSystemBigInt` on arguments).
It also includes the `Expando`, `WeakReference` and `Finalizer` classes,
which are just intended as stand-alone implementation classes for accessing
platform-specific functionality.
Change-Id: Ib770c265edff127a289a67fe72d15b9ff0499407
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287180
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Only the fields of a scrutinee type that are used in the cases are
now shown in the test expectations. When the field is not present,
for instance when the scrutinee type is nullable, or the fields are
only present on (some of) the subtype of the scrutinee type, the
fields are shown to be missing with a `-`.
Change-Id: I2d36b230e979dc929d083cfb8f9cdb9f1143d380
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287280
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This chances the analyzer and CFE representation of constant values
to use the internal constant-to-text which doesn't include the
node type and in most cases resembles the source code corresponding
to the value.
For now, this is for creating less noise in the test. For the release
of the feature we need a more thorough handling since these texts
can be user facing when producing error messages.
Change-Id: I5b83d8b0c030e4ffb66422057acf5511619368e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287200
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Judging by several test cases that have shown up in co19 tests and
informal discussions, it appears to be a common expectation that a
pattern like `int? x?` or `int? x!` should promote `x` to
non-nullable. Previous to this change, this didn't work in general.
Consider:
Object? o = ...;
switch (o) {
case int? x?:
print(x.isEven); // (1)
}
At (1), the null-check happens *before* the required type check of the
variable pattern; therefore it promotes the matched value type to
`Object`. This is not a subtype of the required type of the variable
pattern (which is `int?`), therefore, previous to this change, `x` was
not promoted.
With this change, since the matched value type of `Object` is
non-nullable, the required type of the variable pattern is
re-interpreted as its non-nullable counterpart, `int`.
In a fully null-safe program, this is sound, because if the matched
value type is non-nullable, that guarantees that the matched value is
not `null`, and therefore it is equivalent to type check against the
non-nullable counterpart of the required type.
In a program that is not fully null-safe, the matched value might have
originated in a non-null-safe library (and thus might be `null` in
violation of its static type). So, strictly speaking, it is not sound
to re-interpret the required type of the pattern as its non-nullable
counterpart. However, the only way this unsoundness can manifest is
for the matched value to be promoted to non-nullable when it is in
fact `null`, and that is precisely the sort of unsoundness thta we
permit in mixed-mode programs. So this change won't result in
unsoundness escalation.
Bug: https://github.com/dart-lang/sdk/issues/51644
Change-Id: I9479e3c29e12f2a62a9e165b32c3480d7e299c29
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287040
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This improves the support for logical and pattern by making an
approximation of the intersection of spaces. When creating an
intersection between two [SingleSpace]s, if one of the static
types is a subtype of the other, this used for the create
intersection. Otherwise the intersection is modelled by including
an "unknown space" in the result.
Change-Id: Ia9d7324fa13f4b9850aece126de3aab3a1e63d3e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286962
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds a [SpaceCreator] mixin used to share the code that creates
the [Space] for each pattern. This is mixed into the [PatternConverter]
in the analyzer and a similar [PatternConverter] is added to the CFE.
Change-Id: I0b284b1473b464167aa84f1948264efc4120001d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286960
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This propagates information about reported error to the caller of
a shared type analysis. This is used to properly turn errors into
invalid expressions/patterns, as is normally done in the CFE in
face of errors.
Change-Id: Ibb8adedccb8314fabfe18ecaa3559e32ad7267ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286145
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This changes the Space computation for CastPattern to just the
Space for the subpattern. For a non-throwing cast, this is exactly
what the pattern will match.
There is still potential for handling the types rejected by the cast.
For instance recognizing that the (yet) unhandled subtypes of a
sealed type are exhausted by the throw.
Change-Id: Ia846895449f37a970f87a7f6c54a0ff8285df6b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286825
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds a [Witness] class as the result of an exhaustiveness test.
This allows for testing exhaustiveness without having to compute the
textual representation of the witness.
Change-Id: I6225b6d35a23792ecc15ae769e4b70cab93e2229
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286824
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This remove the [Space] class from the old algorithm and instead
encodes the patterns into the new model. The [Pattern] and
[Patterns] classes of the new model have been renamed to
[SingleSpace] and [Space], respectively, and a [Path] class is
added to track the path property used in the model of the new
algorithm.
Change-Id: I0c86c738807030be2f9b59f3aefb5bfcf5bbaeee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286501
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This allows us report more specific errors.
Bug: https://github.com/dart-lang/sdk/issues/51505
Change-Id: I6e40af1fedce55886a58b954721154db933ede17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286605
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This improves the exhaustiveness handling for null assert patterns
by extending the space of the subpattern with the null space. This
reflects the fact that null assert will throw on `null` and can
therefore be considered to cover that case.
Change-Id: If344eaaa55dcc70474f45519b53586e7d36e6e80
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286400
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change improves the fallback exhaustiveness algorithm so that it
also takes advantage of the old, pre-patterns exhaustiveness logic for
enums. This ensures that the fallback exhaustiveness algorithm won't
seem like a regression to users who are used to the old pre-patterns
behaviour. This required extending the old algorithm to handle
new-style switch statements (which have a different representation
from classic switch statements in the CFE) as well as switch
expressions.
We also turn on the fallback exhaustiveness algorithm by default.
Unit tests can still disable it by temporarily setting the global
variable `useFallbackExhaustivenessAlgorithm` to `false`.
The hope is that this algorithm will be short-lived; we are just using
it so that if we decide to enable pattern support in the near future,
users will experience something that is sound. That is, it may
require `default` or `_` cases more often than is strictly necessary,
but it shouldn't ever allow a non-exhaustive switch in a place where
an exhaustive switch is required.
Change-Id: I4a8b7f996b109c4ee8832f286c3b3bf3b216fe8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284840
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This adds explicit handling of the remaining patterns in exhaustiveness.
All these patterns are handled trivially but with TODOs for where we might
want to improve handling.
Asserts are added to flag if a pattern is unhandled.
Change-Id: I82bfccda396316c718685b4d810f259c25771f00
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/285321
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This adds support for union directly in the exhaustiveness algorithm
meaning that we can support deeply nested or-patterns without having
to eagerly expand the patterns.
For instance, without support for unions,
case (true || false, true || false):
would have to be expanded to
case (true, true):
case (true, false):
case (false, true):
case (false, false):
before performing exhaustiveness.
Now, we instead perform the expansion in-place and only we need to.
That is, when filtering by subtype `true` of `bool`, we only consider
the row
(true, true || false)
as remaining, because the row
(false, true || false)
won't match anyway.
Change-Id: I1a6402bd21b81bf40924ac0048b683936ce9f608
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/285263
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This removes the old algorithm for exhaustiveness checking and
ports the relevant tests to use the new algorithm.
Change-Id: I7aee3c991e2735299ab4ddc743848b4845fb9250
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284882
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds support for generic types in exhaustiveness checking.
There are two main obstacles:
1) Types that are not Dart subtypes might be related in the context
of exhaustiveness. For instance
sealed class A<X> {}
class B extends A<num> {}
method<T>(A<T> a) {
switch (a) {
case B(): ...
}
}
Here B is not a Dart subtype of A<T> but must still be a subtype
in the context of exhaustiveness since T could be num at runtime.
2) It is non-trivial to compute the subtypes of a generic sealed class
that is both sound and precise enough to be useful. For instance
sealed class A<X> {}
class B extends A<num> {}
class C<X> extends A<X> {}
class D<X extends num> extends A<X> {}
class E<X extends E<X>> extends A<X> {}
Computing the subtypes of A<F> for some type F, we would like to
exclude B (assuming F is not a supertype of num) because it
cannot be inhabit A<F>, and include C<F> so that we recognize
that C<F> exactly covers all C instances of A<F>. We would also
like to include D<F> but if we don't include the added `extends
num` bound, we might conclude that D<num> is _not_ sufficient to
cover D<F>. And what to do about E, can we even come up with a
type that represents the valid values?
The solution is threefold:
1) We add an 'overapproximate' function of types, which
replaces all type variables with their default types. This will compute
A<dynamic> for A<T>, A<int> for A<int>, A<List<dynamic>> for A<List<T>>,
and E<dynamic> for E<T extends E<T>>. This is similar to instantiate-
to-bounds, but is recursive.
We use this to test whether a type without type variables is a potential
subtype. For instance testing B <: overapproximate(A<F>) = A<F> shows
that B _cannot_ be a subtype of A<F>, and testing
B <: overapproximate(A<T>) = A<dynamic> shows that B _can_ be a subtype
of A<T>.
2) For finding subtypes of a sealed type, we recognize the case
when a type is a trivial subtype in which all type variables are passed
directly to the superclass, for instance like C<T> in the example. For
other cases we overapproximate the this type of the subclass.
3) To ensure that the [StaticType] can be subtype in the normal Dart
sense but also handle the overapproximation when computing sealed
subtypes, a new [WrappedStaticType] is added. This bridges the subtype
relation such that for instance B, when created as a sealed subtype
of A<T>, is both a subtype of A<num> (as it normally is) and of A<T>,
which it is by construction.
Change-Id: I9970c46009938ef15625e1193faf916b7544ce0b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284681
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This is a reland of commit f17e9732c5
Original change's description:
> [analyzer/cfe] Report an error when declaring a mixin class with final, interface, or sealed.
>
> Change-Id: Ia1393851dffaab55c31d04d4e81bfae83a7bd67f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283126
> Commit-Queue: Kallen Tu <kallentu@google.com>
> Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
Change-Id: Ic8185f38477b2eeff624ee391868d7260e0ed4cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284486
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
This unit test makes sure that parenthesizing a variable pattern
doesn't destroy its ability to track the flow analysis consequences of
a boolean expression.
No code changes were are required, since the implementation passes the
test. But prior to
https://dart-review.googlesource.com/c/sdk/+/282482 this test would
have failed, so it seems reasonable to include it as a unit test to
prevent regressions.
Change-Id: If5595a346757e608bc133846062ec37f47bc3e1e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284485
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
It turns out that some time ago I got rid of the logic that depends on
this; the associated functionality is still there, but it's tracked
automatically by flow analysis via
`_PatternContext._matchedValueInfo`, so we no longer need to track it
in the shared analysis logic.
Change-Id: Ia38e0baf5f599c929aa2000aade41473b997f80a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284480
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This reverts commit f17e9732c5.
Reason for revert: Merged this and forgot there were dependencies that needed to be merged first.
Original change's description:
> [analyzer/cfe] Report an error when declaring a mixin class with final, interface, or sealed.
>
> Change-Id: Ia1393851dffaab55c31d04d4e81bfae83a7bd67f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283126
> Commit-Queue: Kallen Tu <kallentu@google.com>
> Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
TBR=scheglov@google.com,johnniwinther@google.com,kallentu@google.com,dart-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: Ia339aac26ecd20aa8725cc9109919e3cbef6363b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283741
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Previously, if multiple switch cases shared a body, and at least one
of those cases promoted a match variable using a `when` clause, the
promotion would not be carried over to the merged variable seen in the
shared case body. This was happening because promotions performed in
the `when` clause were applied to the promotion key associated with
the client's representation of the variable, whereas flow analysis was
computing the state of the merged variable based on the promotion keys
used internally while visiting the pattern (which don't include
promotions from the `when` clause).
With this change, flow analysis now computes the merged variable state
based on the promotion keys associated with the client's
representation of the variable components, so promotions from `when`
clauses take effect.
In the process, I've moved a lot of the tracking of these promotion
keys from the `TypeAnalyzer` class to the `_FlowAnalysisImpl` class.
This avoids the need to expose more flow analysis internals through
its public API.
Fixes#51399.
Bug: https://github.com/dart-lang/sdk/issues/51399
Change-Id: I8f1bb6e49ceb8441bb743c63af61c119df9041f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283441
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The parser wrongly flagged any `const (...)` in a constant pattern
context and not just the intended `const ()`.
Closes#51415
Change-Id: Id7b0621cda4a144ac186dea55dbcbeaf041349bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283602
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds support for record types in the exhaustiveness algorithm.
The original algorithm was based on that record pattern would
match fields on all types, but that is no longer the case. Instead
record patterns only match corresponding to their own type. For this
reason the testing code is updated to create record spaces in relation
to a type. For instance, when the test create a record space {x: B}, it
is know create in relation to a type, say (x: A, y: A), and the create
space will therefore have (x: *, y: *) structure where the y: component
is implicitly Top, similar to how object patterns are used.
Unlike the Dart record types used for type checking and inference, the
record types used for exhaustiveness do not take the field types into
account for its subtype relation. This is avoid conclusions like
(int i, Object o) and (Object o, int i) having no values in common because
their corresponding types (int, Object) and (Object, int) are not subtypes
of each other. Instead, the subtype relation for record types used for
exhaustiveness only use the structure of the record to determine whether
two types are related.
Note though, that fields of a record type still know the type of the field.
This is used when expanded a record type into a space; the field spaces
will be derived from the field types in this case.
Change-Id: I84735d827494bcf384fd5f419d71933830ff5d15
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283182
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This optional error fires if patterns are enabled and the type
analyzer encounters a switch that is required to be exhaustive (i.e. a
switch expression, or a switch statement with an always-exhaustive
type), and flow analysis cannot prove that the switch is exhaustive.
This is intended to be available as a temporary workaround if we
decide to ship an early beta of the "patterns" feature before
exhaustiveness checking is sufficiently ready. We won't enable it
unless we need to, and we won't ship the final patterns feature with
it enabled.
Change-Id: I8c4c65c21abdc32b91537b3f30e7fd86f446f571
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283060
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This makes the unit tests clearer, since it's possible to tell the
meaning of each argument. It also simplifies the underlying unit
testing logic that formats the errors.
Change-Id: I7212fe0c909ca0b627f8a8889621af3a62a63f00
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283132
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
