The code that was previously owned by the analyzer team
(OWNERS_ANALYZER) is now owned by either the Dart Model team
(OWNERS_MODEL) or the developer experience team
(OWNERS_DEVELOPER_EXPERIENCE). Accordingly, we don't need
OWNERS_ANALYZER anymore.
Change-Id: I9a4d2e2462a15ba9ec8f3046cdca77ba9d3af13c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410564
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Moving forward, the Dart Model team will own the following packages:
- _fe_analyzer_shared
- analyzer
- analyzer_cli
- analyzer_utilities
- front_end
- frontend_server
- kernel
- testing
In follow-up CLs I will create an OWNERS file for the developer
experience team, and then remove the OWNERS files for the old analyzer
and CFE teams.
Change-Id: Id7cf38ea41a6d3f9ca44f43fae1f310426a31e29
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/409841
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The new lint, called `analyzer_public_api`, verifies that the analyzer
public API satisfies the following properties:
- No method, function, getter, setter, or supertype in the public API
refers to a non-public type.
- No `export` declaration in the public API shows a non-public name.
- No declaration in the public API has a name ending in `Impl`.
- No file in the public API has a `part` declaration that points to a
file that's not in the public API. (If it did, then the other checks
could be circumvented.)
A new annotation is added, `@AnalyzerPublicApi()`, allowing
declarations in `package:analyzer/src` or
`package:_fe_analyzer_shared/src` to be marked as part of the analyzer
public API. This is necessary because some parts of the analyzer
public API need to be declared elsewhere and then exported by the
analyzer.
A few lint violations have been ignored using `ignore:` comments. I
will try to clean these up in follow-up CLs.
Fixes https://github.com/dart-lang/sdk/issues/60058.
Bug: https://github.com/dart-lang/sdk/issues/60058
Change-Id: I0047a73dec8a29e2ffe03dd3a90f7e41ca2e27b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/409763
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
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>
Paul Berry