This includes introspection support, support for annotating and executing macros targeted at enums and enum entries, and support for creating library augmentations of enums with proper syntax (including enum entries).
I also refactored some of the Class support to be more general so we can share interfaces where appropriate.
Change-Id: Ie9111ff280405496e55e32478a19c104341aee37
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294100
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This fixes a minor bug in flow analysis which was preventing it from
recognizing when a switch statement was trivially exhaustive, meaning
one of its reachable cases was guaranteed to always match.
This mostly addresses
https://github.com/dart-lang/language/issues/2980, but flow analysis
still fails to recognize that:
- A list pattern containing a just a single rest pattern always
matches (unless the rest pattern has a subpattern that may fail to
match).
- A null check pattern always matches if its subpattern always matches
and the matched value type is non-nullable.
- The relational pattern `!= null` always matches if its subpattern
always matches and the matched value type is non-nullable.
Fortunately, these drawbacks are small and don't lead to unsoundness.
I'll try to address them in follow up CLs.
Bug: https://github.com/dart-lang/language/issues/2980
Change-Id: Ie9f8564cde66a5a2c41114033ca3ff0e1a0f139a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293860
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This handles Never, and as a consequence, empty sealed types in
exhaustiveness. Since these contain no value, we should not try to
exhaust them. This avoid invalid non-exhaustive errors in these cases.
Included is handling of a scrutinee with invalid type as Never in the
CFE, thus avoid cascading non-exhaustive or unreachable errors.
Change-Id: Ife097731bb5399c42bf83f1d77aff773346adfb6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293682
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This updates the message report for non-exhaustive switch statements
and expressions to include the witness in the problem message and
a reduced witness, which doesn't include properties that fully cover the
static type. The message is also split into two messages; one for
switch statements and one for switch expressions, allowing for a
better wording regarding the default/wildcard pattern case.
Change-Id: I17db657ef12ade5d47fa96bf69b8807e33ed5b8c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293040
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds support for extension members in exhaustiveness checking. These are different from regular members in that the type cannot be derived from the matched type but instead is determined by the required type of the object pattern.
To support this a new ExtensionKey is added which holds the static type of the property and whose identity is determined by the name of the property _and_ the type of the receiver (taken from the required type of the object pattern).
When expanding properties, the type of the ExtensionKey is used when the
SingleSpace doesn't have the corresponding property instead of looking up the property type on the static type of the SingleSpace.
Closes#51854
Change-Id: I7a54005972d0640b7dc79e92950bf6d1f89c3fd0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292741
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
The WrappedStaticType was wrongly based on the NonNullableStaticType
even though it could be nullable through its components. This made
the WrappedStaticType(Null, T & bool), i.e the Null type that is also
implicitly a T, which is the nullable part of T & bool?, not seen as
a subtype of Null.
The WrappedStaticType is moved to be a subclass of _BaseStaticType and
the isSubtypeOf implementation is updated accordingly.
Closes#51897
Change-Id: I6ac87c56d709b85f0db28efd327ff41b220ea00d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292701
Reviewed-by: Paul Berry <paulberry@google.com>
This updates the checking order of the exhaustiveness algorithm to
process the sealed type on its own before checking the subtypes. This
has the benefit that for fields that fully covered by (a supertype of)
the sealed type itself, like a wildcard pattern, we avoid checking
each individual subtype.
For the exponential cases added in
https://dart-review.googlesource.com/c/sdk/+/291800
this avoids the exponential growth, bringing the number of checked
witness candidates from 837932 to 6 for the "subtype" test with n = 30 and from 12207032 to 12 for the "fields" test with n = 10.
The change also fixes a problem in the 'future_or_members.dart' caused by the non-null version of 'FutureOr<dynamic>' still being nullable. The old algorithm tried to use 'Object' as a witness canditate but filtered out 'FutureOr<dynamic>' because 'Object' wasn't a subtype if it. The new algorithm starts by using 'Object?' and therefore sees that 'FutureOr<dynamic>' exhausts it. This is an inherent problem in the modelling of StaticType and it should still be addressed.
Change-Id: Iaa5d5604afc4662fe1983d670638223eae5dbf6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291822
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds handling of type variables with bounds and intersection types
in exhaustiveness checking. These are handled using [WrappedStaticType]s
where the type variable is the implied type and the bound is the
wrapped type from which the subtypes are computed, thereby supporting
sealed types in the bounds.
The change also includes some cleanups a fixes found during
implementation, amongst these a fix to no longer cache the map/list
type identities objects. These were not used as identities, similar to
the value identities used for enum and bool values, but instead as
restrictions on the the static type. These have therefore been renamed
to Map/ListTypeRestriction to reflect that.
Closes https://github.com/dart-lang/language/issues/2878Closes#51819
Change-Id: I56e94e4f0dc6695288ab978687d8c95835535b8d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291220
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This updates the toString on Witness to produce pattern code. The
created pattern is directly derived from the predicates of the
witness and there contain some needless precision, for instance
`[...[...]]` instead of `[...]`. It is the plan to address this in
a follow-up.
Change-Id: Ied7930f36b1e1818540b8c635b18ff92f28e113b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290720
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This changes the analyzer and CFE to use the real exhaustiveness
checking algorithm. The fallback algorithm is kept and will be
removed once we know that the real exhaustiveness algorithm sticks.
Change-Id: Ic9df92c1ca9f7dec4cbdfa138dc6ed39ef2d4df5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288703
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This uses the context type when creating the space for a cast pattern
to include the implicitly covered subtypes in the space. This is done
when the context type is a sealed type which means that we can reason
about which of the subtypes of the sealed type that are implicitly
handled by the throw of the cast.
Change-Id: I3a4f14bf6ca82f59a2c2a3c27bb472a8f38c1613
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/289222
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This removes the "unset" values and uses nullable types instead.
The names and uses of the pattern fields are normalized, using
`matchedValueType`, `requiredType` and `lookupType` consistently
between [Pattern] subclasses.
TEST=existing
Change-Id: Ic79ce17075aa8ce252e1c223b59bef660f32bb7c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288704
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This passes the [StaticType] for the context of a pattern to the
pattern converter. This is used to restrict the static type of the
created space. For instance when creating the space for an untyped
wildcard pattern, the context type will be used instead of the
nullable-object (top) type. For other patterns, if the context type
is a subtype of the type for the pattern itself, the context type
will be used instead.
This has the benefit that when checking for unreachable cases we will
not take a too broad case to mean that it has some that it could match.
For instance in `Foo(:var hashCode)` the space for `var hashCode` would
have been the nullable-object type, and if the preceeding case was
`Foo(:int hashCode)`, the reachable check would fail to see that all
cases are covered since nullable-object is not a subtype of int.
With this change, such cases are now handled.
Change-Id: I5b6248bf79c8cf0b365eee2f3ca78090c3f43512
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288902
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds support for exhaustiveness checking of list types by
contextually dividing the list type into relevant cases for checking.
For instance, the exhaustiveness can be achieved by a single pattern
case [...]:
or by two disjoint patterns:
case []:
case [_, ...]:
When checking for exhaustiveness, witness candidates are created and tested against the available cases. This means that the chosen candidates must be matched by at least one case or the candidate is considered a witness of non-exhaustiveness.
Looking at the first example, we could choose `[...]`, the list of
arbitrary size, as a candidate. This works for the first example, since the case `[...]` matches the list of arbitrary size. But if we tried to use this on the second example it would fail, since neither `[]` nor `[_, ...]` fully matches the list of arbitrary size.
A solution could be to choose candidates `[]` and `[_, ...]`, the empty list and the list of 1 or more elements. This would work for the first example, since `[...]` matches both the empty list and the list of 1 or more elements. It also works for the second example, since `[]` matches the empty list and `[_, ...]` matches the list of 1 or more elements.
But now comes a third way of exhaustively matching a list:
case []:
case [_]:
case [_, _, ...]:
and our candidates no longer work, since while `[]` does match the empty
list, neither `[_]` nor `[_, _, ...]` matches the list of 1 or more
elements.
This shows us that there can be no fixed set of witness candidates that we can use to match a list type.
What we do instead, is to create the set of witness candidates based on the cases that should match it. We find the maximal number, n, of fixed, i.e. non-rest, elements in the cases, and then create the lists of sizes 0 to n-1 and the list of n or more elements as the witness candidates.
Change-Id: I27d594699a65510636a2b7811c60c261a02f9b57
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287680
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
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>
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>
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 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 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 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>
Paul Berry