This CL removes Type and TypeSchema type variables from the abstract
classes with shared code between the CFE and the analyzer. Extension
types SharedTypeView and SharedTypeSchemaView are declared to replace
the type variables.
The update propagates the discipline of distinguishing between types
and type schemas into the clients of the shared code. Now the code in
the CFE and the Analyzer that uses the shared code needs to statically
specify the interpretation of their type objects as either types or
type schemas.
Another benefit of the update is SharedTypeView and
SharedTypeSchemaView being less opaque than the Type and TypeSchema
type variables, which removes the necessity for some code duplication
in abstract methods for types and type schemas.
Finally, the update enables some further changes in the shared code
between the Analyzer and the CFE.
Change-Id: I88e8cfcd47d4f721974b4f2612521e85bb54c30f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379302
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
SharedType and its subtypes now all declare one recursive type
variable Type with the bound SharedType<Type>. It allows to treate
SharedType and its subtypes as an abstract familty of types that has a
specific structure.
More specifically, the type variables Type and TypeSchema in the
abstract classes for shared algorithms between the Analyzer and the
CFE can now be defined recursively as extending SharedType<Type> and
SharedType<TypeSchema>, giving both types and type schemas the
structure of the family of types with the root at SharedType.
One of the benefits for that is that some abstract members become
unnecessary. For example, a type or type schema can now be tested for
having the shape of the type 'dynamic' with a direct is-check,
comparing them, correspondingly, with SharedType<Type> and
SharedType<TypeSchema>.
More importantly, having the family of recursive types lays the
foundation for further work on sharing the type structure between the
Analyzer and the CFE.
Change-Id: I67904f878668c035702092e8c21d3ce66f5ca469
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/378700
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
The shared abstract class TypeConstraintGenerator is introduced and is
set as the parent for both the Analyzer's TypeConstraintGatherer and
the CFE's TypeConstraintGenerator. The interface of the shared
abstract class is minimal, to support the treatment of the discrepancy
between the Analyzer and the CFE around FutureOr types.
The discrepancy between the Analyzer and the CFE is seaprated out into
a smaller method and can be controlled via a boolean flag that
switches between the behaviors of the two frontends. The flag is
called requiredEmptyNullabilitySuffix and is passed as a named
parameter to
TypeConstraintGenerator.performSubtypeConstraintGenerationForFutureOr.
In response to https://github.com/dart-lang/sdk/issues/55344
Part of https://github.com/dart-lang/sdk/issues/54902
Change-Id: I272b57b573377a54977a516ce6e378953bd1c0e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373480
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Fix bracketed references in doc comments that previously pointed to
nowhere, in the following source code:
- Shared type inference logic
(pkg/_fe_analyzer_shared/lib/src/type_inference/...).
- Testing infrastructure that exercises shared type inference logic
and flow analysis (pkg/_fe_analyzer_shared/test/mini_*.dart).
This is part of a larger effort to clean up _fe_analyzer_shared to the
point where the `comment_references` lint can be enabled.
Change-Id: I15e6133dc7631c9a634131f0df3a3ff14f568e3b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375201
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Work towards https://github.com/dart-lang/language/issues/2
The feature is well-specified at the issue, but I will also follow
up with a specification to check into the language repo.
This change implements the feature more-or-less from front to back
(because the back is very close to the front in this case :P; no
"backend" work in the VM, etc). Digit separators are made available
via a new experiment, `digit-separators`.
Care is taken to report a single error when an underscore appears in
an unexpected position (see new `separators_error_test.dart`).
Three test files are added:
* `separators_test.dart` is run with the experiment enabled, and has
no compile-time errors.
* `separators_error_test.dart` is run with the experiment enabled, and
has many compile-time errors.
* `separators_error_no_experiment_test.dart` is run with the
experiment _disabled_.
Change-Id: I7f1b1305d28b708b5ddf83f26188cd6e9ce3dd58
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365181
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This allows TypeAnalyzerOperations.getNullabilitySuffix to be removed,
and allows shared code to access nullability suffixes directly as
properties of a type, in the same way that the analyzer does.
Change-Id: I33ab90798b779534b5b0b111ec5137845b32f23b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/368443
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The "mini_types" representation (used for unit testing of shared flow
analysis and type analysis code) is reworked so that it represents
nullabilities in the same way as the analyzer (and in a more similar
way to the CFE), namely: each type has a field `nullabilitySuffix`
indicating whether the type is followed by `?`, `*`, or neither.
This change ensures that `is` and `as` tests using the mini_types
representation (e.g. `is FunctionType`) will behave the same way as
they ehave in the analyzer and CFE; this in turn should lead to
additional opportunities to share code between the analyzer and CFE.
Change-Id: Ia5d963eb96e225e62df71a406d4024053311df88
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365700
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The `toString` logic in `mini_types.dart` is improved in the following ways:
- The `toString` representation of the "unknown" type is changed from
`?` to `_`, to match the behavior of the mini_types parser.
- Logic for applying parentheses is simplified and moved into the
function `_parenthesizeIf`.
- The boolean `allowSuffixes` (which was not well documented, and
poorly named) is replaced with a boolean `parenthesizeIfComplex`,
and documentation is added to clarify its behavior.
- Unit tests of `toString` are added to `mini_types_test.dart`.
Change-Id: I251e137369b5880017022be2514f00975a511e72
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365660
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This commit builds on the work done in
https://dart-review.googlesource.com/c/sdk/+/362481, which established
the framework for sharing a class hierarchy between the analyzer and
CFE to represent types.
This commit introduces the following new classes:
- `SharedDynamicType`, which represents the common interface between
the `DynamicType` classes in the analyzer and the CFE.
- `SharedInvalidType`, which represents the common interface between
the `InvalidType` classes in the analyzer and the CFE.
- `SharedVoidType`, which represents the common interface between the
`VoidType` classes in the analyzer and the CFE.
This allows 3 methods to be removed from the
`FlowAnalysisTypeOperations` class:
- `isDynamic`, which is no longer needed becasue `is
SharedDynamicType` can be used instead.
- `isError`, which is no longer needed because `is SharedInvalidType`
can be used instead.
- `isVoid`, which is no longer needed because `is SharedVoidType` can
be used instead.
In addition, `getDisplayString` is removed from the
`TypeAnalyzerOperations` class, and replaced with a `getDisplayString`
method in `SharedType`. This does not increase the API surface area of
the analyzer, because the analyzer already has a
`DartType.getDisplayString` method.
Change-Id: Ib8d9d3a7699f3d1e8b9612ca9c8f4134fa19de77
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365303
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
New classes are introduced into the "mini_types" representation to
represent `dynamic`, `FutureOr<T>`, `Never`, `Null`, `void`, and the
"invalid" type. Previously, these were all represented simply using
`PrimaryType`.
Introducing new classes for these types makes the "mini_types"
representation more consistent with the representations used by the
analyzer and the front end. Since the "mini_types" representation is
used solely for unit testing the shared logic in the
`_fe_analyzer_shared` package, it's hard to justify unnecessary
differences between it and the analyzer and front end representations;
these differences just make it harder to effectively share code.
Change-Id: Ie633feef914c5ce4540b9da681a84b7f53fd8f38
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365340
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When analyzing the type test implied by a pattern, flow analysis uses
three variables to control promotion behavior:
- `matchFailsIfWrongType`, which indicates whether flow analysis needs
to account for the possible control flow path resulting from the
type test failing. (This is `false` for cast patterns, because in
the case where a cast pattern fails, an exception is thrown).
- `matchMayFailEvenIfCorrectType`, which indicates whether flow
analysis needs to account for the possible control flow path
resulting from the type test succeeding, but some other check
causing the match to fail. (This is `true` for most list patterns,
because the list pattern will fail to match if the list has the
wrong length).
(Note that `matchMayFailEvenIfCorrectType` doesn't account for the
fact that a pattern match might fail due to failure in a subpattern
match; this is automatically handled by the fact that flow analysis
walks through the complete pattern in the order in which it
executes.)
- `coversMatchedType`, which indicates whether the type test is
guaranteed to succeed due to a subtype relationship between the
matched value type and the type being tested (e.g. a `num x` pattern
is guaranteed to succeed if the matched value type is `int`).
In the case where `matchFailsIfWrongType` is `true`,
`matchMayFailEvenIfCorrectType` is `true`, and `coversMatchedType` is
`false`, flow analysis must account for the fact that there are two
ways that the pattern match might fail: the type test might fail, or
the type test might succeed but then the pattern match might fail for
some other reason.
Before this change, this was done incorrectly, and flow analysis only
accounted for the possibility of the type test failing.
Fixes#55543.
Bug: https://github.com/dart-lang/sdk/issues/55543
Change-Id: I86603ec5f940402313f32177212b7960878db97f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364942
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This commit introduces the following new classes:
- SharedType, which represents the common interface between the
DartType classes in the analyzer and the CFE.
- SharedRecordType, which represents the common interface between the
RecordType classes in the analyzer and the CFE.
- SharedNamedType, which represents the common interface between the
analyzer and CFE representations of a name/type pair.
- SharedUnknownType, which represents the common interface between the
analyzer and CFE representations of the unknown type (`_`).
This allowed three methods to be removed from the
`TypeAnalyzerOperations` class:
- `areStructurallyEqual`, which is replaced by
`SharedType.isStructurallyEqualTo`.
- `asRecordType`, which is no longer needed because `is
SharedRecordType` can be used instead.
- `isUnknownType`, which is no longer needed because `is
SharedUnknownType` can be used instead.
And one method to be removed from the `FlowAnalysisTypeOperations`
class:
- `isSameType`, which is replaced by `operator ==`. (Technically this
could have been done even without introducing a shared class
hierarchy, since `operator ==` is defined in the shared base class
`Object`).
The long term goal is to fill out the shared class hierarchy to cover
other kinds of types (interface types, function types, void, etc.),
and to move most of the shared logic from the analyzer and CFE
DartType class hierarchies into shared code. This should reduce the
risk of implementation skew between the analyzer and CFE, and to
streamline the implementation of future features. Additionally, the
hope is to eventually remove, or drastically simplify, classes like
`TypeAnalyzerOperations`, so that the code in `_fe_analyzer_shared`
can be written in simpler and more straightforward way.
Change-Id: I5d3a929057959f77ccff8dbed5671f9bca6259c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362481
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This avoids redundant computation of the matched value type, so it
should lead to a modest (but perhaps negligible) performance
improvement.
It also paves the way for some future work I'm planning that will
allow details of the type inference process to be logged for debugging
purposes.
Change-Id: I8fb24a5b07b97f17ed045bc8bd2ca9e854233b20
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364800
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Since the types in mini_types.dart are only used in testing, the
algorithms that are specialized to those types aren't themselves
heavily tested. It looks like this typo slipped through the cracks.
Change-Id: I7ec1c8c17e29c7075a5f49418b5a1a06c0fa1028
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363860
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL abstracts the notion of a type parameter that the compiler
should infer for. Since the notion of such a parameter is used
throughout the constraint generation, it is represented as another
type variable in the shared interfaces, similarly to Type, TypeSchema,
and other similar abstractions.
The affected regions of constraint generation are the central points
of that algorithm and don't require additional tests since any test
that requires non-trivial type inference exercises a pass through
those points.
Part of https://github.com/dart-lang/sdk/issues/54902
Change-Id: Idc7fe13952c40e748e761cc90ab74e7ccf45ee50
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357611
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This updates the exhaustive checking algorithm to produce a list of
witnesses instead of a single witness in case of a non-exhaustive error.
This is used to create a witness for each missing subtype when checking
"sealed static types", for instance enums and sealed classes.
The current error reporting isn't changed and only reports the first
witness. Use of the multiple witnesses in error messages and/or lints
must be done in the CFE and analyzer.
Change-Id: I950816f6a9eca16773f182d5d820929bdcb39684
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357160
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This removes the Declaration from RecordFieldDeclaration and renames it
to RecordField. The fields of a record type are not declarations but
are similar to FormalParameter of a FunctionTypeAnnotation; they contain
part of the information for the RecordTypeAnnotation but are not
identifiable on their own.
Change-Id: Iaa9d95d49f2152096b970c6e2d24c524327f933e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/355740
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
In the following expression types, the static type is computed using
the least upper bound ("LUB") of their subexpressions (adjusted as
appropriate to account for the null-shorting behaviors of `??` and
`??=`):
- Conditional expressions (`a ? b : c`)
- If-null expressions (`a ?? b`)
- If-null assignments (`a ??= b`)
- Switch expressions (`switch (s) { p0 => e0, ... }`)
This can lead to problems since the LUB computation sometimes produces
a greater bound than is strictly necessary (for example if there are
multiple candidate bounds at the same level of the class hierarchy,
the LUB algorithm will walk up the class hierarchy until it finds a
level at which there is a unique result). For a discussion of the kind
of problems that can arise, see
https://github.com/dart-lang/language/issues/1618.
This change improves the situation by changing the analysis of these
four expression types so that after computing a candidate static type
using LUB, if that static type does not satisfy the expression's
context, but the static types of all the subexpressions *do* satisfy
the expression's context, then the greatest closure of the context is
used as the static type instead of the LUB. This is the algorithm
proposed in
https://github.com/dart-lang/language/issues/1618#issuecomment-1507241494.
This is theoretically a breaking change (since it can change code that
demotes a local variable into code that doesn't, and then the demotion
or lack of demotion can have follow-on effects in later code). So it
is implemented behind the `inference-update-3` experiment
flag. However, in practice it is minimally breaking; a test over all
of google3 found no test failures from turning the feature on.
Since one of these expression types (switch expressions) is
implemented in `package:_fe_analyzer_shared`, but the other three are
implemented separately in the `package:analyzer` and
`package:front_end`, this change required modifications to all three
packages. I've included tests for the new functionality, following the
testing style of each package. I've also included a comprehensive set
of language tests that fully exercises the feature regardless of how
it's implemented.
Since `package:front_end` has many different implementations of `??=`
depending on the form of the left hand side, I've tried to be quite
comprehensive in the language tests, covering each type of assignable
expression that might appear to the left of `??=`.
Change-Id: I13a6168b6edf6eac1e52ecdb3532985af19dbcdf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353440
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
- Adds hasInitializer and hasConst to VariableDeclaration.
- Renames isStatic to hasStatic to be consistent with other members.
- Improves serialization tests by randomizing some values, which
should help to catch ordering errors in serialization.
Change-Id: I44199b1b058444510b9fa55afe0611187b90fc95
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352540
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Morgan :) <davidmorgan@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Previous attempt to use AST and builder was removed.
Also, after talk with Brian, removed scopes, and replaced with more
course grained, but simpler collision detection. If there is a declaration with the same name as prefixed, the name stays prefixed. Similarly, if there is an unprefixed invocation.
Change-Id: If2b0ce530ac81482e5bfd066d6df43e1a5d34799
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350683
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Chloe Stefantsova