This changes how scopes are computed for libraries and classes
(work on extensions is still pending). The change supports the new
shared scope need for augmentations, in which a declaration on the
origin or any of the augmentations is directly accessible in the
origin and all augmentations.
Change-Id: Ifb76f49bf80fcad2d92a0400b9be623406afb40d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256262
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This updates the SourceLibraryBuilder.origin to return the effective
origin library and not just the immediate origin. In case of an
'import augment' in a part file, the immediate origin is set to the
part "library". Since the part is not a real library, the augmentation
library should not (try to) depend on that library but instead the
library containing the part.
Change-Id: I8ca1345c2e7c5bef71a7a1f9bed41a3bc4e538d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255256
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Several unusual constructs that lead to unreachable code are now
recognized by flow analysis:
- Control flow after an expression of the form `e ?? other` or `e ??=
other`, where `e` has static type `Null` and `other` has static type
`Never`, is considered unreachable.
- Control flow predicated on an expression of the form `e is Never`
evaluating to `true` is considered unreachable.
- Control flow predicated on an expression of the form `e is! Never`
evaluating to `false` is considered unreachable.
- Control flow on the RHS of a null-aware access such as
`e?.property...`, `e?.property = ...` or `e?.method(...)`, where `e`
has static type `Null`, is considered unreachable (Note: this can
arise in the presence of extension methods).
Previously, these behaviors only took effect if `e` was a reference to
a local variable.
Note: the change to `regress/issue_31180` is because I’ve corrected
the behavior of implicit temporary variables to not undergo a type
change from `Null` to `dynamic`, so the dead code part of `null?[1]`
is now erroneous. (I had to make this change in order for the last
bullet above to work properly; without it, the type change to
`dynamic` prevents flow analysis from recognizing that the code to the
right of `?.` is unreachable.) There's no behavioral change to
correct code, but I've captured the behavioral change to incorrect
code in
`tests/language_2/null_aware/null_aware_index_on_null_error_test.dart`.
Bug: https://github.com/dart-lang/sdk/issues/49635
Change-Id: I8b24b3b040a34f897c0b61dcb9bd105be6d0af6d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This adds the flag `isEnumElement` to the `Field` node and uses it
to recognize enum elements for the exhaustiveness computation on
switch statements.
Closes#49697
TEST=pkg/front_end/testcases/general/issue49697/main.dart
Change-Id: I21852f3b063329e043639c825054f538c8ed6536
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255808
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This uses the `Procedure.signatureType` for checking super access
instead of the types derived from `Procedure.function`. This fixes
the checking of super access in face semi-stubs where the parameter
types have a more restrictive but covariant type.
Change-Id: I8b21238687bcec8e5e42a999c5a94d0e65cac28c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255660
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Scope.forEach iterates through the builder immediately mapped in the
scope. For duplicate declarations, this means that it'll give direct access to the last defined declaration and not to the first defined
declaration, which is inconsistent with how we generally handle
duplications. It also doesn't skip builders that are not "owned" by
the scope but merely accessible, which means that we easily have
duplicate handling of patches and augmentations which are part of
both the scope in which the were declared and the scope of the origin.
To normalize the handle of scope, this CL removes Scope.forEach
with iterators that explicit filter what subset of the builder
that we want to have access to. This prepares for the more complex
scope introduced by the augmentation libraries in which all
scopes have access to all declarations from the origin library as
well as other augmentation libraries.
Change-Id: I88bdfb1068fbb4eb9dd6fa3881b86a61104e50e3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255240
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This change breaks flow_analysis.dart into the following libraries:
- assigned_variables.dart (for the AssignedVariables class and related
code)
- promotion_key_store.dart (for the PromotionKeyStore class)
- type_operations.dart (for the TypeOperations mixin and related code)
- flow_analysis.dart (for the rest of flow analysis)
And it breaks mini_ast.dart into the following libraries:
- flow_analysis_mini_ast.dart (functionality specifically concerned
with testing flow analysis)
- mini_ast.dart (functionality not specifically related to flow
analysis)
This is in preparation for trying to share some more type inference
behaviors between the analyzer and CFE.
Note that although the diff is big, the only changes in this CL are
moving code from one place to another, renaming some class members
from private to public, and updating imports.
Change-Id: I71768f03b1e75ed754c7b7af39f6cf7f03c4fe44
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254462
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change splits the `Harness` class into a base class, `Harness`,
which in principle can be used for testing type inference logic in
general, and a derived class `FlowAnalysisTestHarness`, which is
specialized for flow analysis tests.
This is in preparation for trying to share some more type inference
behaviors between the analyzer and CFE.
Change-Id: Ic56b8dd8748065ca59e246e0d804946cc69203c3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This pipes the expression type for a generated property setter, such
that synthesized variables in let expressions created for the generated
setter expression are typed correctly.
Before this change a let variable created for an extension property set
would use the value type even though the extension property setter is
method with a void return type.
Change-Id: I3fb0aaef7893e333352be81a2c8fced2a0a869fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253781
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds
* for_in.dart with ForInResult and ForInVariable classes
* inference_results.dart with all *Result and NullGuard classes
* inference_visitor_base.dart with InferenceVisitorBase and its helpers
* mixin_inferrer.dart with MixinInferrer
* object_access_target.dart with the ObjectAccessTarget classes
Leaving
* inference_visitor.dart with InferenceVisitor(Impl) and helpers
* type_inferrer.dart with TypeInferrer(Impl) and helpers
Makes
* closure_context.dart a library instead of a part
Change-Id: Ib26fae2f2b2ee6c18edcd32dc12d35d1072d4a8e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254020
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This reverts commit a5fda59219.
Reason for revert: breaks calling extension setters with `?.`, see b/241059207
Original change's description:
> [cfe] Use `void` for let-expressions for extension property set
>
> This pipes the expression type for a generated property setter, such
> that synthesized variables in let expressions created for the generated
> setter expression are typed correctly.
>
> Before this change a let variable created for an extension property set
> would use the value type even though the extension property setter is
> method with a void return type.
>
> Change-Id: I1e7d31eaf1410bb06d55e2845403865e0c7af452
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252742
> Commit-Queue: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Aske Simon Christensen <askesc@google.com>
TBR=johnniwinther@google.com,askesc@google.com
Change-Id: Iaafd12833939cbd38e09787fcdb5a4c78a964656
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253440
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Ilya Yanok <yanok@google.com>
Reviewed-by: Ilya Yanok <yanok@google.com>
This pipes the expression type for a generated property setter, such
that synthesized variables in let expressions created for the generated
setter expression are typed correctly.
Before this change a let variable created for an extension property set
would use the value type even though the extension property setter is
method with a void return type.
Change-Id: I1e7d31eaf1410bb06d55e2845403865e0c7af452
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252742
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Deletes the outline stubber as it's not necessary on any backend.
DDC should compile the entire sources and outline dill in one step.
dart2wasm operates similarly, and so only needs the modular transformer.
dart2js moves the erasure to a global transform.
Also, this CL reverts now unnecessary plumbing that was needed for the
outline stubber.
Change-Id: Ic085c4fad5a6bdfc7d6916f7fa575c6ef9b20110
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253000
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
The resolution of the redirecting factories should happen after the
type inference because the inference needs the original, unresolved,
representation of the program. Some areas of the CFE attempt to finish
the delayed computations, including the resolution of the redirecing
factories, before the inference phase. An example of such area is the
enum member generation. It has to happen early for proper scope
construction. At this stage we know that we can delay the resolution
of the redirecting factory invocations becuause it will be attempted a
second time later, after the inference is done.
Closes https://github.com/dart-lang/sdk/issues/49429
Change-Id: I65c1f903ce2783580785cd1ad61291c28a924937
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252943
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This updates the incremental test to cover all naturally occuring
advanced invalidation results.
Removes duplicateInLibrary since it was surpassed by problemsInLibrary.
Change-Id: I1669bd93220b83a911328629de92bb6d8a0ec826
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251551
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The result of the advanced invalidation is recorded and used for
testing, replacing the 'expectsRebuildBodiesOnly' yaml property
with an 'advancedInvalidation' property.
Change-Id: I520d329b100c1a7be72d6eff9d277b8e94df3a2c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251462
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Each variable is mapped to a unique integer "promotion key", which is
used as an index into the `FlowModel.variableInfo` map. This paves
the way for adding entries to `FlowModel.variableInfo` to represent
promoted properties. It also cleans up the previous hacky way we used
to use `null` as a map key to represent `this`.
In a future CL I plan to try to replace `FlowModel.variableInfo` with
a list rather than a map. This should improve both memory and CPU
usage.
As a side effect of this change, many classes related to flow analysis
no loger need a `Variable` type argument, including the `EqualityInfo`
class (which is exposed to clients).
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: I853ca835c6b36ab9865bd187973c6524a7471db0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/250120
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
* Sets sort-of already did this. But only if defind as e.g. <type>{}
so it was a Set up-front. If the type was not given it is created as
a Map and is later converted. In the convertion some type was lost.
This is fixed in this CL.
* Maps now do this to; implementation mostly copied from set/list
handling.
Fixes https://github.com/dart-lang/sdk/issues/49307
Change-Id: I73437c1ba2ae563f202061a7151da3f54a10c233
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/250083
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This change moves the `variableType` method from the class
`TypeOperations` to a new class, `VariableOperations`, which in turn
allows removing the type parameter `Variable` parameter from
`TypeOperations`. A new class, `Operations`, is introduced to serve
the role served previously by `TypeOperations` for flow analysis
clients (i.e. it is the base class that clients should extend).
This paves the way for a future CL that will remove the type parameter
`Variable` from other classes inside flow analysis.
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: Ic45d07a0f873b692fda4b6f807c1130ac592b010
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/250108
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Move TypeDeclarationResolver to be available in the Declaration phase.
Add IntrospectableType interface, and IntrospectableClassDeclaration which implements it (we will eventually have IntrospectableMixinDeclaration, IntrospectableEnumDeclaration, etc).
Migrate ClassIntrospector to InterfaceIntrospector, which operates on IntrospectableType instances instead of ClassDeclaration instances.
Question: Possibly `InterfaceIntrospector` should have a different name, maybe just `TypeDeclarationIntrospector`?
Change-Id: Ifd202bad61eeae5f7d76d769d9d96a866c0fecdb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247060
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Johnni Winther