This field was only used to populate expectation strings in "id"
tests; it did not affect any user-visible behavior of the analyzer or
CFE.
Including information in "id" tests that doesn't affect any
user-visible behavior isn't helpful. Removing this field will enable
some upcoming flow analysis refactoring work (I intend to remove the
`ExpressionInfo._type` field, replacing its remaining usages with a
more reliable mechanism).
Change-Id: Id4c6593fae4ef25b8c21f0625e6c1f9eaa766e17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/406403
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This moves the creation of class builders for anonymous mixin application to after the creation of the normal class builders.
A ClassDeclaration interface is added to support class builders from different fragments. This is also a step towards creating class builders fully through fragments.
TEST=existing
Change-Id: Ia6b4a17648bdc89b89fd3cfdfe39d24d347b6341
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/407420
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This removes the support running macros in the CFE.
The scanner and package:kernel still have support for the macro modifier. This will be removed in a follow-up.
The metadata expression parser is deliberately left in, since it might serve as the basis for a parser AST.
Change-Id: I06d91eb0fac2e7a71e6afde647b03be3814dbd5f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/406963
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Morgan :) <davidmorgan@google.com>
This updates the exhaustiveness checking to return the shortest witness when no more cases match a value.
This also fixes an exponential case that occurred when checking for reachability.
Closes#59927
Change-Id: I82ede75113ca5d361875620287f7ce3c5fb2f5d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/405120
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Since the class `TypeConstraintGatherer` (which is only used in
`_fe_analyzer_shared`'s unit tests) is now used both by
`type_constraint_gatherer_test.dart` and by `mini_ast.dart`, it makes
sense for it to live in its own file.
Change-Id: I7c8a58cfbf3724e2c8313b701345bc47ce032522
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404060
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Extension methods can no longer be disabled. This CL removes the option
from the scanner config and the parser related specific recovery.
It also removes any specific (triggered) test of the functionality.
A follow-up CL will do the same for NNBD.
Change-Id: Ia385008e5ed1333fb37697b8fe424b8759bce198
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/403581
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The following shared getters are renamed so that their names are
distinct from the corresponding getters in the analyzer:
- `SharedFunctionTypeStructure.positionalParameterTypes` is renamed to
`positionalParameterTypesShared` to be distinct from the analyzer's
public getter `FunctionType.positionalParameterTypes`.*
- `SharedFunctionTypeStructure.returnType` is renamed to
`returnTypeShared` to be distinct from the analyzer's public getter
`FunctionType.returnType`.
- `SharedNamedFunctionParameterStructure.type` is renamed to
`typeShared` to be distinct from the analyzer's public getter
`FormalParameterElement.type`.
- `SharedNamedTypeStructure.type` is renamed to `typeShared` to be
distinct from the analyzer's public getter
`RecordTypeNamedField.type`.
- `SharedRecordTypeStructure.positionalTypes` is renamed to
`positionalTypesShared` to be distinct from the analyzer's public
getter `RecordType.positionalTypes`.*
- `SharedRecordTypeStructure.sortedNamedTypes` is renamed to
`sortedNamedTypesShared` to be distinct from the analyzer's public
getter `RecordType.sortedNamedTypes`.
- `SharedTypeParameterStructure.bound` is renamed to `boundShared` to
be distinct from the analyzer's public getter
`TypeParameterElement2.bound`.
*Note that `FunctionType.positionalParameterTypes`,
`RecordType.positionalTypes`, and `RecordType.sortedNamedTypes` were
unintentionally exposed as part of the analyzer's public API. In a
previous CL I marked them as deprecated.
These renames pave the way for changing the analyzer's `DartType`
class so that it implements `SharedTypeStructure<TypeImpl>` rather
than `SharedTypeStructure<DartType>` (without the renames, the public
getters mentioned above would all have to be changed to have type
`TypeImpl`, and that in turn would expose `TypeImpl` through the
analyzer public API, which we don't want to do).
Once `DartType` implements `SharedTypeStructure<TypeImpl>`, that will
allow all the other uses of `SharedTypeStructure<DartType>` in the
analyzer to be gradually migrated to
`SharedTypeStructure<TypeImpl>`. Once that is done, `DartType` can be
changed so that it no longer implements
`SharedTypeStructure<TypeImpl>` at all (`TypeImpl` will implement
`SharedTypeStructure<TypeImpl> instead). This will free us up to make
future changes to the `SharedTypeStructure` base class without
inadvertently exposing those changes through the analyzer public API.
This is part of a larger arc of work to change the analyzer's use of
the shared code so that the type parameters it supplies are not part
of the analyzer public API. See
https://github.com/dart-lang/sdk/issues/59763.
Change-Id: I0686fdeae304f8948484516f0249841b79e7da6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/403625
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The following shared getters are renamed so that their names are
distinct from the corresponding getters in the analyzer:
- `SharedFunctionTypeStructure.sortedNamedParameters` is renamed to
`sortedNamedParametersShared` to be distinct from the analyzer's
getter `FunctionTypeImpl.sortedNamedParameters`.
- `SharedFunctionTypeStructure.typeFormals` is renamed to
`typeParametersShared` to be distinct from the analyzer's getter
`FunctionTypeImpl.typeFormals`.
- `SharedNamedFunctionParameterStructure.name` is renamed to
`nameShared` to be distinct from the analyzer's getter
`ParameterElement.name`.
- `SharedNamedTypeStructure.name` is renamed to `nameShared` to be
distinct from the analyzer's getter `RecordTypeNamedFieldImpl.name`.
These renames pave the way for switching the analyzer's use of these
shared types over to the new element model. They're necessary because
when the analyzer switches over to the new element model:
- `FunctionTypeImpl.sortedNamedParameters` will no longer have the
correct type to override
`SharedFunctionTypeStructure.sortedNamedParameters`; instead, it
will be necessary to convert each named parameter to a corresponding
element in the new element model (`FormalParameterElementImpl` or
`ParameterMember`).
- `FunctionTypeImpl.typeFormals` will no longer have the correct type
to override `SharedFunctionTypeStructure.typeParametersShared`;
instead, it will be necessary to use
`FunctionTypeImpl.typeParameters` (which is a list of
new element model type parameters).
- `ParameterElementMixin` will no longer implement
`SharedNamedFunctionParameterStructure`; instead,
`FormalParameterElementImpl` and `ParameterMember` (which are
classes in the new element model) will implement it. The class
`FormalParameterElementImpl` deliberately doesn't have a `name`
getter; instead it has a `name3` getter, with slightly different
semantics (it returns `null` rather than the empty string when there
is no name).
Change-Id: I629e45b6fc588e6a86f7590aab853064e31ab661
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/402220
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change introduces a new mixin, `NullShortingMixin`, with a type
parameter `Guard` for the data structure used by the client to desugar
null-aware accesses. The mixin maintains a stack of these guards, and
provides methods that the client can use to manipulate the stack:
- `startNullShorting` adds an entry to the stack; it should be called
when the client encounters the `?.` part of a null-aware expression.
It also provides two hooks that the client can override if desired:
- `handleNullShortingStep`, called whenever an entry is removed from
the stack; this will let the CFE know when it should de-sugar a null
short using a "let" expression.
- `handleNullShortingFinished`, called whenever a sequence of entries
is removed from the stack; this will let the analyzer know when it
should change the static type of an expression as a result of
null-shorting.
Also, a new optional parameter, `continueNullShorting`, is added to
`TypeAnalyzer.analyzeExpression`. If this parameter is `false` (the
default value), then any null shorting that is started during analysis
of the expression (due to the client calling `startNullShorting`) will
be terminated before returning. If it is `true`, then null shorting
won't be terminated, so it will extend to the containing
expression. For expression types that are able to extend null shorting
that appears in their target subexpression (e.g., method calls and
property accesses), the `visit` or `analyze` method should pass
`false` for this parameter when making a recursive call to analyze the
target.
Finally, the `NullShortingMixin` has a getter `nullShortingDepth`,
that `TypeAnalyzer.analyzeExpression` uses to determine when null
shorting should be terminated, and a method `finishNullShorting`, that
actually does the work of terminating null shorting. In principle,
clients don't need to invoke these parts of the `NullShortingMixin`
API. However, since the CFE doesn't always use
`TypeAnalyzer.analyzeExpression` (favoring its own internal methods
`InferenceVisitorImpl.inferExpression` and
`InferenceVisitorImpl.inferNullAwareExpression`), the CFE will need to
use them.
The "mini_ast" tests of flow analysis formerly used a method called
`nullAwareAccess` to exercise the flow analysis effects of null-aware
constructs. This was hacky and confusing, and is now unnecessary,
since the shared infrastructure now fully supports null-shorting. So
this method has been removed and replaced by the ability to mark a
method invocation or property access as null-aware.
This change only builds the infrastructure for shared analysis of
null-shorting; the analyzer and CFE still handle null shorting on
their own. In follow-up CLs I will change the analyzer and CFE to make
use of the shared mechanism.
Change-Id: Ide25a915c4d06eab751b87c1c2745749d23a8114
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/399480
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Rework the methods `checkIR`, `checkSchema`, and `checkType`, so that
rather wrap the `CollectionElement`, `Expression`, or `Statement` node
in a new node that performs the check, they return the existing node,
and store the value to be checked in a private field. The checks are
now performed as a side effect of `dispatchCollectionElement`,
`dispatchExpression`, or `dispatchStatement`.
The major advantage of this change is that previously, adding one of
these checks to an expression in a "mini_ast" test caused an extra
call to be made to `analyzeParenthesizedExpression`, so that flow
analysis information would be propagated from the wrapped node to the
node that performs the check. At the moment, extra calls to
`analyzeParenthesizedExpression` don't have any effect other than
forwarding flow analysis information, so this is benign. But in a
follow-up CL, I plan to add null-shorting support to "mini_ast" tests,
and this will mean that a side effect of
`analyzeParentehsizedExpression` is to terminate null
shorting. Re-working the checks now will ensure that when
null-shorting support is added, the checks won't terminate null
shorting as an accidental side-effect.
Change-Id: I484f29b3ce63e15ab19100462d6a4b5c6b875d34
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/399025
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is the shared base class for all representations of the type
`Null`. This allows the shared codebase to use `is` tests to tell when
a type is `Null`.
Change-Id: I98059b60c7eaab9c9f1e3f7addb7913dffc9cf9d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396380
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL removes the unnecessary conversion from `TypeStructure` types
to `SharedTypeView` and `SharedTypeSchemaView` and back. By design,
the shared constraint generation method is operating on
`TypeStructure` types and uses the shared procedures named with the
'Internal' suffix to transform those types. In this CL the shared
procedures that are only used in the shared constraint generation
method or in 'Internal' procedures are converted to 'Internal'
themselves, and the corresponding update in the parameters accepted
and returned by those procedures is made.
Part of https://github.com/dart-lang/sdk/issues/54902
Change-Id: Ic8596b342bde7e78093e990fc0f12f705ff6dee1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395962
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This required improving the implementation of `operator == ` for
function types, to check that the bounds match (after performing
appropriate substitutions). It also required modifiying
`FunctionType.substitute` to apply the substitution to the bounds.
The API for `TypeParameter` was changed slightly, so that it's
possible to distinguish between an explicit bound of `Object?` an an
implicit one. This allows `FunctionType.toString()` to avoid
outputting `extends Object?` next to a type parameter that has an
implicit bound.
Change-Id: Iad31a44a1f87ca0cd830b8c802495b7ce2c1caab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396141
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Generic function types have the following special behaviors:
- Their implementations of `hashCode` and `==` take care to ensure
that if two generic types differ only in the names of their type
parameters (i.e. they are alpha-equivalent), they will compare equal
and have the same hash code. For example, `T Function<T>()` and `U
Function<U>()` represent the same type. This logic takes advantage
of `Type.substitute` and `Type.gatherUsedIdentifiers`, added in
recent CLs.
- When parsing a generic function type, references to type formals can
appear in the return type or parameter types. E.g. in the function
type `T Function<T>()`, the return type `T` refers to the type
formal `T` declared by the function type. It doesn't refer to a `T`
declared elsewhere. To make this possible, the parameter
`typeFormalScope` has been added to `Type.materialize`; this carries
the meaning of type formals through the recursive process of
transforming a `_PreType` into a corresponding `Type`.
In a follow-up CL, I will use this new support to unit test the
generic function type logic that's recently been added to
`TypeConstraintGenerator` (see
https://dart-review.googlesource.com/c/sdk/+/393860).
Change-Id: Ib5e392f844990185b2602d22809eac5599505aff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395687
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The `_PreType` class (and its subclasses) mirrors the `Type` class,
except that it represents types in a more raw form, before identifiers
have been resolved to their associated meanings. For example, the
`_PreType` representing `int` is a `_PrePrimaryType` whose `typeName`
field is the string `int`, whereas the `Type` representing `int` is a
`PrimaryType` whose `nameInfo` field points to the `TypeNameInfo`
object representing the class `int`.
Parsing of `Type` objects is now a two-step process: the string is
first converted to a `_PreType`, and then the `_PreType` is
materialized into a `Type` by looking up each identifier in it in the
`TypeRegistry`.
This will be needed in a follow-up CL that introduces support for
generic function types, to support the possiblity that a generic
function type's return type refers to one of its type parameters
(e.g. `List<T> Function<T>()`). The reason this is will be needed is
because the meaning of the return type (`List<T>`) can't be determined
until the `TypeParameter` object representing the type parameter `T`
has been created.
Change-Id: I9f4a73bdc0f38380518a9c39db8c788234adb806
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395686
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This method will be used by a follow-up CL that adds support for
generic functions, since the implementation of `==` and `hashCode` for
generic functions needs to perform substitutions in order to recognize
that alpha-equivalent types (such as `T Function<T>()` and `U
Function<U>`) are equal, and those substitutions need to avoid name
collisions with identifier names that already appear in the type.
Change-Id: Ifd237a9842791f440e285d89e9d80b898e996411
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395685
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This method will be used by a follow-up CL that adds support for
generic functions, since the implementation of `==` and `hashCode` for
generic functions needs to perform substitutions in order to recognize
that alpha-equivalent types (such as `T Function<T>()` and `U
Function<U>`) are equal.
Change-Id: If641c4d0ae48708abf3701853014dc52dfc559c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395684
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, the `hashCode` and `==` logic for the `Type` hierarchy
used a short-cut: convert the type to a string and then hash or
equality-check the result.
However, that trick won't work for generic function types (which I
intend to implement in a follow-up CL), because generic function types
that are alpha-equivalent (i.e. equivalent except for the names of
type formals) need to be considered equal. So, as preparation for
supporting generic function types, this change adds full
implementations of `hashCode` and `==` for all the classes in the
`Type` hierarchy.
Change-Id: I8312d22cabaeb8c38cd58da80acdb3f068ee5c2b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395620
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
The class hierarchy for `PrimaryType` has several subtypes to
represent special types in Dart:
- DynamicType (for `dynamic`)
- FutureOrType (for `FutureOr<...>`)
- InvalidType (for the invalid type)
- NeverType (for `Never`)
- NullType (for `Null`)
- VoidType (for `Void`)
When constructing a `PrimaryType` for one of these special types, we
need to make sure that the type that's being ultimately constructed is
the proper subtype, otherwise algorithms that do `is` tests on the
`Type` hierarchy will behave incorrectly.
This change adds an assertion to the `PrimaryType` constructor to
verify that the appropriate subtype of `Type` is being constructed.
Change-Id: I347cc4893da265b35e97636479700a92a8e61541
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395560
Reviewed-by: Kallen Tu <kallentu@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, NamedFunctionParameter was derived from NamedType. This
avoided a tiny amount of code duplication, but the benefit was really
tiny. Decoupling the two classes simplifies the implementation of a
follow-up CL that I have in progress, which will allow the mini_types
framework to represent function types.
Change-Id: I29bff36ab76bbf344cf7204f2503b006a88a4cf8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395422
Reviewed-by: Kallen Tu <kallentu@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This adds support for replacement a [StaticGet] with the constant
initializer of the referenced constant during evaluation of macro
metadata. Currently constants defined in the same library or
compilation is supported. For full support the constant initializers
need to be included in the outlines/summaries.
Change-Id: I219f85dded63342d4e3f957f0b7321badbe376a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392907
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
The exhaustiveness model relies on null being extracted from nullable, for instance modeling `int?` as `int|Null`. This failed on type variable that are potentially nullable but not explicitly nullable. For these `Null` should be extract from their bound and not from themselves.
The logic in the getStaticType method now uses `isNullable` to determine both when to extract and to combine, so to avoid extracting but not combining `Null` for type variables and also not combine but not extract for instance for `void`.
Closes#56998
Change-Id: I47c2d0d6535ca66fe00e6344b11550c4308a7388
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392944
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
There are two pieces of information flow analysis needs to know about
an equality test operand (i.e., an operands of `==`, `!=`, or
`identical()`):
- Their static types. This is used for reachability (e.g., flow
analysis knows that if `f()` has type `Null`, then the body of `if
(f() != null)` is unreachable).
- Whether they take the form of a null literal or a reference to
something promotable. This is used to determine when an `if` test
should promote a something to a non-nullable type.
Previous to this change, both pieces of information were captured by
`FlowAnalysis.equalityOperand_end` into an `ExpressionInfo` object,
and then those objects were passed into
`FlowAnalysis.equalityOperation_end`.
With this change, the client is now responsible for passing the static
types of the operands as separate arguments to
`FlowAnalysis.equalityOperation_end`, and the only information
captured by `equalityOperand_end` is whether the operand is a null
literal or a reference to something promotable.
This has two advantages:
- It avoids unnecessary allocations when analyzing code that doesn't
have flow analysis consequences, since flow analysis no longer needs
to allocate an `ExpressionInfo` for every equality test operand; it
only has to allocate them for null literals and references to things
that are promotable (which is a much smaller number of allocations).
- It means that `FlowAnalysis.equalityOperation_end` no longer needs
to use the `type` field of `ExpressionInfo`. This helps build toward
an eventual goal I have of removing this field, so that
`ExpressionInfo` will simply be a container for a pair of flow
models (one representing the flow state if the expression is `true`,
one representing the flow state if the expression is `false`). I
believe this will make flow analysis easier to reason about, and
will help build toward a long term goal of cleaning up bugs in the
"why not promoted" logic.
Making this change required adding a little bit of plumbing to the
analyzer, so that when analyzing an invocation of `identical`, it
keeps track of both the `ExpressionInfo` and the static type of the
operands; previously it just had to keep track of an `ExpressionInfo`
for each operand. The performance impact of this additional tracking
should be negligible, since this tracking doesn't happen for
invocations of anything other than `identical`.
Change-Id: I3e5473af095f3c8a747e9f527d7e14a21269dc95
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/389361
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This delays the resolution of the identifier in metadata, such the
parsed annotation expression is initially unresolved and
`Expression.resolve` must be called in order to resolve it.
This execises the support for references to identifiers declare via
macros, which will initially occur as unresolved identifiers.
Change-Id: I4863ce950ded0b9d2c1744421d9751cddea6e80c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/391641
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This adds a shared metadata parser to be used for macros. The parser
create a new AST which supports unresolved ASTs and delayed AST resolution.
An id-test is added for the generated AST from both CFE and analyzer.
Change-Id: Ie51817493fa6e668727a7af3a55cd22e2be722b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/391100
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Paul Berry