Weaves the flag `inference-update-4` through to `FlowAnalysis` and updating both the analyzer and CFE point-of-entry to include the flag.
This flag will be used in `flow_analysis.dart` to hide upcoming bug fixes to flow analysis.
Change-Id: Ib0004eb4bcf0b6e579116632b5973fe969e51e90
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/388582
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Previously, the base `ExpressionInfo` class contained four fields:
- `type`: the type of the expression.
- `ifTrue`: a flow model describing the state of the program after the
expression is evaluated, assuming the expression evaluates to
`true`.
- `ifFalse`: a flow model describing the state of the program after
the expression is evaluated, assuming the expression evaluates to
`false`.
- `after`: a flow model describing the state of the prorgam after the
expression is evaluated, making no assumptions about what value the
expression evaluates to.
The `after` field was largely redundant, since it tracked the same
information as `FlowAnalysisImpl._current`. In fact, flow analysis
contained a substantial amount of code to copy from
`ExpressionInfo.after` to `FlowAnalysisImpl._current`, or vice versa,
in order to keep the two in sync.
The one exception was in `FlowAnalysisImpl.conditional_end`, which is
called at the end of visiting a conditional expression (`e1 ? e2 :
e3`): it joined the `after` flow models from `e2` and `e3` in order to
determine the state of the program after the conditional expression
completes. To preserve this behavior, a small amount of extra
accounting logic had to be added to the handling of conditional
expressions, to keep track of these flow models. (`e2.after` is now
stored in `_ConditionalContext.thenModel`, and `e3.after` comes from
the state of `_current` at the time of entry into
`FlowAnalysisImpl.conditional_end`).
Change-Id: I46e771f8b029550d43a5fe50366177f189a6a91d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/388081
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
This brings the "mini types" representation of records (which is used
for _fe_analyzer_shared unit tests) into alignment with the behavior
of analyzer and CFE record types (which sort their fields), and makes
the representation more consistent with that of function types.
Since all implementations of record types now maintain named fields in
sorted order, documentation has been added to
SharedRecordTypeStructure to indicate that the fields returned by the
`namedTypes` getter are sorted.
This exposed a minor bug in the error recovery logic in the shared
pattern type analyzer: upon encountering a record pattern with
duplicate field names, after reporting the appropriate error, it would
nonetheless attempt to create a record type containing duplicate
fields (potentially breaking the assumptions made by other code that
handles record types). This bug was fixed by adjusting the record
pattern analysis logic so that it drops duplicate field names when
constructing record types.
Change-Id: Ib06b86df980afcf17896e10ac7856f994aeda86f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/388041
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, the "mini types" representation used in
`_fe_analyzer_shared` unit tests represented unpromoted type
parameters using the `PrimaryType` class (which was also used for
interface types and special built-in types like `void`) and
represented promoted type parameters using a separate
`PromotedTypeVariableType` class.
This CL changes the "mini types" representation to use a single
`TypeParameterType` class for both unpromoted and promoted type
parameters. This parallels the representation used by the analyzer
and CFE, so it should help pave the way for sharing type system logic
between the analyzer and CFE.
To allow the `Type` constructor to distinguish whether a given
identifier represents an interface type or a type variable, tests must
register all type names they will need, using either the static method
`TypeRegistry.addTypeParameter` or the static method
`TypeRegistry.addInterfaceTypeName`.
To prevent the type names registered by one unit test from interfering
with those registered by another, tests should call
`TypeRegistry.init` in a `setUp` callback and `TypeRegistry.uninit` in
a `tearDown` callback. Methods in `TypeRegistry` contain error checks
to help make sure these calls aren't forgotten.
Change-Id: I701842ad94899c819f1a059e660510a616d00456
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/387822
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change combines function-handling logic from the analyzer's
`TypeConstraintGatherer._functionType0` and the CFE's
`TypeConstraintGatherer._isNullabilityAwareSubtypeMatch` methods into
`TypeConstraintGenerator.performSubtypeConstraintGenerationForFunctionTypes`,
which is in `_fe_analyzer_shared`.
The CFE and the analyzer have some pretty significant differences in
how they represent function types:
- In the analyzer, all function parameters are in a single
`parameters` list; each element of this list (of type
`ParameterElement`) can be queried to find out if it is named or
unnamed, and if it is required or optional. A convention enforced
partially by the `FunctionType` constructor is that the `parameters`
list stores reqired unnamed parameters first, then either optional
unnamed parameters or named parameters; named parameters are sorted
by name. The analyzer provides additional getters
`namedParameterTypes`, `normalParameterNames`,
`normalParameterTypes`, `optionalParameterNames`, and
`optionalParameterTypes`, which provide other views of this
information (for example, `namedParameterTypes` contains just the
named parameters, as a map from name to `ParameterElement`).
- In the CFE, unnamed and named parameters are in two separate lists
(`positionalParameters`, of type `List<DartType>`, and
`namedParameters`, of type `List<NamedType>`); in
`positionalParameters`, required parameters come before optional
ones. A single integer (`requiredParameterCount`) indicates how many
elements of `positionalParameters` are required, and by convention,
`namedParameters` is sorted by name.
In order to share logic between these representations, I had to come
up with a common API that these two representations could be easily
adapted to. The analyzer's representation proved to be easier to
adapt, so I based the common API mostly on the CFE's representation,
but with some name changes for clarity. The shared API is:
- `positionalParameterTypes` gets a list of positional parameter types
- `requiredPositionalParameterCount` tells how many entries in
`positionalParameterTypes` are required.
- `returnType` gets the function type's return type.
- `sortedNamedParameters` gets a list of information about named
parameters. The list elements are sorted by name, and each element
of this list is of type `FunctionParameterStructure` (a common
interface implemented both by the analyzer's `ParameterElement` and
the CFE's `NamedType`).
- `typeFormals` gets a list of the function type's formal type
parameters.
To minimize the performance impact of adapting the analyzer to this
API, the analyzer computes `positionalParameterTypes`,
`requiredPositionalParameterCount`, and `sortedNamedParameters` at the
time a `FunctionType` is constructed. Hopefully this should not be too
much of a performance hit, since doing so does not take too much more
effort than checking that the named parameters are sorted (which the
`FunctionType` constructor was already doing).
This is based on previous work by Chloe Stefantsova in
https://dart-review.googlesource.com/c/sdk/+/386480.
Change-Id: Iefe18d72771146399d81747ceab9c929516b0523
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386322
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Mini-ast function types now support optional positional parameters and
named parameters (both required and optional).
This will allow more _fe_analyzer_shared functionality to be unit
tested.
Change-Id: I3425e0742de2bee511f2f3d303dd3ed6f26c289c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386729
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These tests cover just the portion of the subtype constraint
generation mechanism that's currently shared between the analyzer and
the CFE. I plan to add more unit tests as more functionality becomes
shared.
Note that as part of this change, I've eliminated the methods
`performSubtypeConstraintGenerationForFutureOrRightSchema` and
`performSubtypeConstraintGenerationForFutureOrLeftSchema`, and instead
made `_performSubtypeConstraintGenerationForFutureOrInternal` public
(renaming it to `performSubtypeConstraintGenerationForFutureOr`). My
rationale for this change is as follows:
- It makes testing easier, since only one method needs to be tested
rather than two.
- Removing these two methods simplifies the call sites in the analyzer
and CFE, since instead of having to use an `if` test to decide which
method to call, they can simply pass in the appropriate boolean
switch for the `leftSchema` argument.
Change-Id: I0911c80fc8e9a4fbdd3dd0063dd203066006c218
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386861
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
The return type of this method was previously
`TypeDeclarationMatchResult?` (with no explicit type arguments),
meaning that the generic type parameters of
`TypeDeclarationMatchResult` would be filled in by
instantiate-to-bounds as `Object, Object, Object`. But the
implementations always return the more precise type
`TypeDeclarationMatchResult<TypeDeclarationType, TypeDeclaration,
TypeStructure>?`, and the use sites all expect this type. Adding
explicit type arguments improves type safety and probably allows the
compiler to elide some of the type casts involved in pattern matching.
Also, the "mini_ast" implementation of this method contained a subtle
bug: instead of using `unwrappedType.type` for the `typeDeclaration`
Change-Id: Ic7bffc1b0b3e9bfc86c0168d4e6bdf442af8ae39
argument, it should use `unwrappedType.name`. This ensures that if the
type being matched is generic, the generic arguments don't show up in
the `typeDeclaration`.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386681
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously the implementation of this method was a stub.
It turns out that all the necessary infrastructure was in place
already, however the type arguments supplied by MiniAstOperations to
TypeAnalyzerOperationsMixin and TypeAnalyzerOperations needed to be
changed: in the "mini_ast" representation of types, an
InferableParameter is represented by a String, not a
PromotedTypeVariableType. This is because InferableParameter is meant
to represent the declaration of the type parameter
(StructuralParameter for the CFE, TypeParameterElement for the
analyzer), not the type itself. The types used for unit testing in
_fe_analyzer_shared don't have a separate notion of the declaration of
a type parameter, so we just use its name.
Implementing this logic required adding a method
`TypeSystem.matchTypeParameterType`, which checks if a Type is a type
parameter type, and returns the name of the type parameter if so. I
based this on the previously existing `TypeSystem._isTypeVar` method
(which performed the same job but did not return the type parameter
name).
I also took the liberty of fixing a flow analysis test that treated
`T` as a type variable but failed to mark it as a type variable by
calling `addTypeVariable`.
This should help pave the way for unit testing more of the shared
infrastructure for types.
Change-Id: Ia7a9777ec3d90a5886567dcb9f831e388e372f32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386607
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
E.g. we might do this
```
$ out/ReleaseX64/dart-sdk/bin/dart compile aot-snapshot pkg/_fe_analyzer_shared/test/scanner_benchmark.dart
Generated: /usr/local/google/home/jensj/code/dart-sdk/sdk/pkg/_fe_analyzer_shared/test/scanner_benchmark.aot
$ for type in --bytes --bytes0 --string --stringtobytes --count ; do out/ReleaseX64/dart-sdk/bin/dartaotruntime pkg/_fe_analyzer_shared/test/scanner_benchmark.aot pkg/kernel/lib/ast.dart $type; done
Scanned 466534 bytes 1000 times in 0:00:04.413011
Found errors 0 times
That's 105.71784208106438 bytes per microsecond
Scanned 466534 bytes 1000 times in 0:00:04.911947
Found errors 0 times
That's 94.97944501437007 bytes per microsecond
Scanned 466532 string characters 1000 times in 0:00:05.413169
Found errors 0 times
That's 86.18463602374136 string characters per microsecond
Scanned 466532 string characters as bytes 1000 times in 0:00:06.722731
Found errors 0 times
That's 69.39620222793386 string characters as bytes per microsecond
Scanned 466534 bytes 1000 times in 0:00:00.641854
Found errors 0 times
That's 726.8537704836302 bytes per microsecond
```
to see that scanning pre-0-at-the-end'ed bytes scan at ~105 bytes/µs,
doing a copy to add the 0 at then end, then parse bytes scan at ~95,
scanning strings runs at ~86, converting strings to bytes, then scanning
the bytes at ~69 and - for comparision - just running through the bytes
counting linebreaks runs at ~726.
The benchmark is also useful for comparing optimizations.
Change-Id: I67c12850505e7f712660fd353575e8c7a455f112
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385920
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
When determining whether a switch statement is exhaustive, it's
important for the exhaustiveness algorithm to ignore cases containing
`when` clauses, since a `when` clause creates the possiblity that the
case won't match.
Previously, the way this was done in the analyzer was for the
`SpaceCreator.createRootSpace` method to create an unknown space for
cases containing `when` clauses. This approach produced the correct
behavior when determining whether the switch statement as a whole was
exhaustive, but since it discarded information about the pattern being
matched, it limited the ability to determine whether an individual
case was reachable, leading to
https://github.com/dart-lang/sdk/issues/56710.
To fix this, `SpaceCreator.createRootSpace` is changed so that it
always produces a space that describes the case pattern, regardless of
whether a `when` clause is present, and instead,
`computeExhaustiveness` is responsible for ensuring that the case is
properly excluded from the determination of whether the switch is
exhaustive. This allows `computeExhaustiveness` to properly computate
whether each individual case is reachable, even for cases that have
`when` clauses.
This change in approach produced some minor differences in the test
cases in `pkg/_fe_analyzer_shared/test/exhaustiveness/data`, but these
differences are not user-observable.
Fixes https://github.com/dart-lang/sdk/issues/56710.
Change-Id: I36629a77c4c1832fb1b8abb6ea7b109e0ca14373
Bug: https://github.com/dart-lang/sdk/issues/56710
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384326
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This warning is similar to the existing `UNREACHABLE_SWITCH_CASE`
warning, except that it warns if the `default` clause of a switch
statement is unreachable due to all the `case` clasuses fully
exhausting the switched type.
To make the implementation easier, I changed the API for the
`reportExhaustiveness` method in `_fe_analyzer_shared` (which is the
primary entry point to the shared exhaustiveness checker). Previously,
this method returned a list of `ExhaustivenessError`, where each list
element was either an `UnreachableCaseError` (indicating that a
certain case was unreachable) or a `NonExhaustiveError` (indicating
that the entire switch statement was not exhaustive). If the caller
passed in `false` for `computeUnreachable`, `UnreachableCaseError`s
would not be returned, so the returned list would either be empty or
contain a single `NonExhaustiveError`.
The new API renames the types for clarity:
- `NonExhaustiveError` becomes `NonExhaustiveness`, to highlight the
fact that it's not necessarily an error for the switch's cases to be
non-exhaustive; it's only an error if the scrutinee's static type is
an "always exhaustive" type and there is no `default` clause.
- `UnreachableCaseError` becomes `CaseUnreachability`, to highlight
the fact that it's not an error for a case to be unreachable; it's a
warning.
Also, the new API adds instances of `CaseUnreachability` to an
optional user-provided list instead of returning a newly created list;
this allows callers to communicate that they don't need to see
`CaseUnreachability` information by passing `null`. This frees up the
return type to simply be an instance of `NonExhaustiveness` (if the
cases are not exhaustive) or `null` (if they are exhaustive). This
makes it easier for the analyzer to decide whether to issue the new
warning, because it doesn't have to dig around the list looking for an
instance of `NonExhaustiveness`.
The new warning has an associated quick fix (remove the unreachable
`default` clause). This quick fix uses the same `RemoveDeadCode` logic
in the analysis server that the existing `UNREACHABLE_SWITCH_CASE`
warning uses.
Fixes https://github.com/dart-lang/sdk/issues/54575.
Bug: https://github.com/dart-lang/sdk/issues/54575
Change-Id: I18b6b7c5249d77d28ead7488b4aae4ea65c4b664
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/378960
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
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>
Kallen Tu