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>
We've decided to rename enum shorthands to dot shorthands. It describes the entire feature better. It's not only for enum values. We'll update the experiment name before the implementation goes in, that way our users can use a flag that matches the actual feature name.
Additionally, roll co19 to b14b0802e696a60c79b00d0f052e26fb986f0faf so we can avoid an infra failure with co19 using what's now an unknown feature flag (enum-shorthands).
2025-02-06 sgrekhov22@gmail.comFixesdart-lang/co19#3067. Rename the static access shorthand feature experiment flag (dart-lang/co19#3068)
Cq-Include-Trybots: luci.dart.try:analyzer-linux-release-try
Bug: https://github.com/dart-lang/sdk/issues/57037
Change-Id: I031e3bce8166145b24dbb77acf259d78e6e00f0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/407603
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Kallen Tu <kallentu@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>
The constructors for `SharedTypeView<TypeStructure>` and
`SharedTypeSchemaView<TypeStructure>` are changed so that they accept
`TypeStructure` rather than `SharedTypeStructure<TypeStructure>`.
For context, I'm currently in the middle of migrating the analyzer so
that it passes a type argument of `TypeImpl` instead of `DartType`
when using generic types that accept a `TypeStructure` type
argument. The purpose of this change is to ensure that when a given
use of `SharedTypeView` or `SharedTypeSchemaView` has its type
argument changed to `TypeImpl`, the type checker will ensure that the
corresponding constructor argument satisfies `TypeImpl`.
There is no change to runtime behavior.
Change-Id: I34d540312b567e390e7dfa535806051e0d5f2868
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404900
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@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 simplifies working with `@Native`-annotated functions by allowing the native type to be omitted when it can be inferred from the Dart function's signature. While this was previously supported for `@Native` fields, it now applies to functions as well.
Before this change, you needed to specify the native type explicitly:
```
@Native<Void Function(Pointer)>()
external void free(Pointer p);
```
After this change, the native type can now be omitted if it's clear from the Dart signature:
```
@Native()
external void free(Pointer p);
```
TEST=tests/ffi/native_assets/*
CoreLibraryReviewExempt: VM only
Closes: https://github.com/dart-lang/sdk/issues/54810
Change-Id: Ied5407fcd2f49d85284cb7817f0c8cad2a73626b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/400840
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Moritz Sümmermann <mosum@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Change the analyzer's use of the following shared classes and mixins
to supply `PromotableElement2` instead of `PromotableElement` as the
type parameter that represents promotable variables:
- `AssignedVariables`
- `AssignedVariablesForTesting`
- `CaseHeadOrDefaultInfo`
- `DemoteViaExplicitWrite`
- `FlowAnalysis`
- `GeneratedTypeConstraint`
- `MatchContext`
- `MergedTypeConstraint`
- `NonPromotionReasonVisitor`
- `SwitchExpressionMemberInfo`
- `SwitchStatementMemberInfo`
- `TypeAnalyzer`
- `TypeAnalyzerErrors`
- `TypeAnalyzerOperations`
- `TypeAnalyzerOperationsMixin`
- `TypeConstraintFromArgument`
- `TypeConstraintFromExtendsClause`
- `TypeConstraintFromFunctionContext`
- `TypeConstraintFromReturnType`
- `TypeConstraintGenerator`
- `TypeConstraintGeneratorMixin`
- `TypeConstraintOrigin`
- `UnknownTypeConstraintOrigin`
- `VariableBinder`
- `VariableBinderErrors`
This ensures that all references to variables within the shared code
are using the new analyzer element model.
As a result of this type change, a lot of analyzer code that
interfaces with shared logic needs to change to use the new element
model.
Also, a few additional members need to be added to
`BindPatternVariableElementImpl2`, `JoinPatternVariableElementImpl2`,
`LocalVariableElementImpl2`, and `PatternVariableElementImpl2` to
allow members of the underlying `_wrappedElement` to be accessed.
Change-Id: Ie925eeb82523c769c4d869a37551718f75d334ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/400660
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
When `PrefixedIdentifierResolver.resolve` rewrites a prefixed
identifier expression to a property access (which it does when the
prefix is an expression having record type), instead of making a call
from `ResolverVisitor.visitPropertyAccess` to
`ResolverVisitor.visitPropertyAccess` to resolve the rewritten
expression, use a private helper method for both code paths.
This ensures that all `visit` methods in the `ResolverVisitor` are
called solely from `ExpressionImpl.accept` or from
`ExpressionImpl.resolveExpression` (at least as far as expressions are
concerned). This will pave the way for a follow-up CL, in which I will
make sure that all expression resolution is done through the
`TypeAnalyzer.analyzeExpression` method. That will in turn allow the
analyzer to use the shared implementation of null-shorting introduced
in https://dart-review.googlesource.com/c/sdk/+/399480.
Change-Id: I782e10be2f58fdc0991b6d917f81bedd856485a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/399627
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
Autogenerated files was formatted with the new style, so if one for
instance formatted the file via the IDE or by saying
`out/ReleaseX64/dart-sdk/bin/dart format pkg/front_end/lib/` we'd get
*a lot* of changes which isn't great.
This CL sets the formatter version for the auto-generated files,
hopefully avoiding such things.
Change-Id: I4f92aafde7c77e7c78179f78bf821979a25ec12c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/398884
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@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>
Paul Berry