Support for `when` clauses requires flow analysis integration, so that
`when` clauses can promote variables, e.g.:
f(int x, String? y) {
switch (x) {
case 0 when y != null:
// y is known to be non-null here
}
}
Support for labels in switch statements had a small flaw: we weren't
reporting an error in the case where a label shared a case body with a
pattern that tried to bind a variable, e.g.:
f(int x) {
switch (x) {
L: // Error: does not mind the variable `y`
case var y:
...
}
}
Change-Id: I0b2bb4721a6b3a8f7898df682b24b75ddb6e44ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256605
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change introduces the TypeAnalyzer methods
analyzeConstOrLiteralPattern, analyzeExpression,
analyzeInitializedVariableDeclaration, analyzeSwitchExpression,
analyzeSwitchStatement, analyzeUninitializedVariableDeclaration, and
analyzeVariablePattern. These are sufficient to analyze legacy switch
statements and legacy variable declarations, as well as switch
statements and switch expressions involving either constants or
variable patterns.
Although the code is not used in the analyzer or front end yet, it is
unit tested in isolation, and it's integrated into the existing flow
analysis unit tests.
A few minor tweaks had to be made to flow analysis to support this new
functionality. There should be no visible effect to existing analyzer
or front end behavior.
Change-Id: Ie8ec31ca92d5f2f7a7f6f6a20ca1baba3c6b28f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256604
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
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 change introduces the mixin TypeAnalyzer, which is intended to be
mixed into analyzer and front end classes to provide shared logic for
type analysis of Dart code. This work is currently experimental, and
not hooked up to the analyzer or front end, but the eventual hope is
that it can replace the logic that's currently duplicated between the
analyzer's ResolverVisitor and the front end's InferenceVisitorImpl.
A secondary goal of introducing this code is to allow some of the
static consequences of the patterns proposal to be explored now, even
before parser support is finished.
To avoid introducing additional code duplication while the project is
in this experimental phase, I'm going to attempt to restrict myself as
much as possible to prototyping functionality that is not yet
implemented in the analyzer or front end. This initial CL is an
exception; it introduces the method `analyzeIntLiteral`, which
duplicates logic that already exists in both the front end and
analyzer that analyzes integer literals. I'm doing this because it's
just complex enough to serve as a validation of the basic approach,
and because integer literals will be handy in writing test cases for
the expanded switch functionality in the patterns proposal, which I
plan to work on next.
Although the code is not used in the analyzer or front end yet, it is
unit tested in isolation, and it's integrated into the existing flow
analysis unit tests.
Change-Id: I07c7cd709eec9e8492669f2dc8db57fb7c10798f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255081
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is a preparatory step towards sharing type inference logic
between the front end and analyzer. The ExpressionTypeAnalysisResult
interface will be returned from the shared `analyze` methods for
expressions, as a container for all the information needed by both the
client (front end or analyzer) and by the code that analyzes the
containing expression or statement.
For now, the only implementation of the interface is
SimpleTypeAnalysisResult, which represents the result of analyzing a
simple expression with no null shorting. In future CLs I plan to add
more types, recording information such as:
- For an integer literal, whether it was implicitly converted to
`double`.
- For a binary operator or a compound assignment, the resolved binary
operator.
- Information necessary to coordinate null shorting.
And so on. There is a placeholder method `resolveShorting` that will
encapsulate null shorting logic, but it doesn't do anything special in
the case of SimpleTypeAnalysisResult.
At the moment, only test code is affected.
Note that this approach isn't free; every time we analyze an
expression we wrap the resulting type in a SimpleTypeAnalysisResult,
so there's a cost of one allocation per expression in the user's
program. I don't believe this will be a problem in practice, because
the front end uses a similar approach, so it is already paying this
penalty.
Change-Id: Ic407089b6eb9e717c65d73766e7c836e161ef0da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255080
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@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>
A get of a promotable field on a non-promotable field shouldn't
promote, otherwise this code would be unsound:
class C {
D get _field1 => D();
}
class D {
final int? _field2 = randomBool() ? 1 : null;
}
main() {
var c = C();
if (c._field1._field2 != null) {
// Problem: `c._field1` returns a different `D` each time, so there's
// no guarantee that `c._field1._field2` is non-null the second time we
// access it!
print(c._field1._field2.isEven);
}
}
This change has no user-visible effect because field promotion is not
yet enabled.
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: I9a60cd343dff14cded03df700d7c2b62a251487a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255821
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The current [StringCanonicalizer] implementation has some issues:
* It hangs on to large [Uint8List]/[String] objects in it's cache
=> This requires users (such as analyzer) to clear the cache
frequently
* Has api that works on dynamic input (which is assumed to be String
or List<int> / Uint8List)
=> Call sites have typing information we loose when doing the call
* It uses dynamic [] calls to compare input bytes with cached bytes /
input strings with cached strings
=> Dynamic calls come with overhead
=> Will cause substring generation for every character comparison
=> Will compare bytes with strings (which doesn't make sense)
To address these issues we
* Use the canonicalized [String] to compare against instead of the
(much larger) source strings, thereby no longer hanging on to large
strings in the canonicalizer cache (it's still an issue with
[Uint8List]s though)
* Make seperate API for canonicalization of strings, sub-strings or
sub-utf8-bytes and use it from the token implementation.
* For canonicalization of strings use String.== (instead of
char-by-char comparison)
* For canonicalization of sub-strings use String.charCodeAt instead of
[] (which creates substrings)
* Seperate out cache node entries into two classes and reduce memory
consumption of the nodes that represent strings by 16 bytes (it
does an additional `is` check on lookups in the cache, but that is
better than paying for dynamic calls on the payload - which
causes the compiler to do implicit checks)
=> This CL reduces RAM consumption and makes CFE scan/scan_bytes benchmarks a little faster.
TEST=ci
Change-Id: I157c298d26d25ac5da82c32eedfa270a590156f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255121
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Some instances of analyzer have a heap of 600 MB, containing 400k
StringToken/StringTokenImpl.
This CL combines two existing fields which will shrink those objects
by 16 bytes, which saves 6 MB.
We densly number all token & keyword types so they can be looked up in
an array.
TEST=ci
Change-Id: I8431db243d55a316e7a72678844d031356c40e79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254920
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Martin Kustermann <kustermann@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 improves separation of concerns, since the `PromotionKeyStore`
class isn't really concerned with what fields are promotable; it's
just a mechanism for assigning unique integer identifiers to
promotable things.
I've moved `_promotableFields` to the main `_FlowAnalysisImpl` class.
To avoid having to add it as a separate argument to a lot of
[FlowModel] methods, I've created a new [FlowModelHelper] interface
that provides these methods with access to several fields in
`_FlowAnalysisImpl`.
Change-Id: I0280d0c0b95714521afbe68a07e7b3b54f23b7df
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254003
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, it was unclear what information was stored in
_IfNullExpressionContext._previous. It turned out that it was the
"shortcut state", i.e. the flow state if the LHS of the `??` was
non-`null`. I've renamed variables and added comments to clarify
this. Also, based on the implementation of
`ifNullExpression_rightBegin`, it looked like it might update
`_current`, but in fact it did not (because `tryMarkNonNullable`
always returns an `ExpressionInfo` whose `ifFalse` is unchanged); I've
refactored the code so that this is clearer, and added a comment
explaining why it is the right thing to do.
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: Ib8a5235f9b9482f4b290ad90686385514660a95d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251142
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Previously, flow analysis used the class `ReferenceWithType` to track
references for which it knew the type, and `Reference` (and its
subclasses) to track references for which it didn't know the type (or
for which the type was unimportant).
This change removes the `Reference` class hierarchy, in favor of just
using the integer promotion keys. This should reduce the number of
memory allocations that flow analysis needs to make.
A few pieces of information previously maintained by the `Reference`
class hierarchy are now tracked elsewhere: the logic for computing
non-promotion reasons is now in
`_FlowAnalysisImpl._getNonPromotionReasons`, and the property name and
property member (previously maintained by `_PropertyGetReference`) is
now maintained by `_PropertyReferenceWithType` (a new subclass of
`ReferenceWithType`).
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: I72f2d80b3256bf8b9c9a30bcc55666ecb7c31e47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/250242
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, flow analysis's tracking of properties was done through
the `VariableModel.properties` field. This field wasn't properly
updated during joins, rebases, and handling of try/finally; as a
result, flow analysis failed to detect some possible promotion
opportunities for fields. This wasn't previously a problem, because
we didn't support field promotion (the only reason flow analysis
tracked fields at all was so that error messages could explain that
field promotion *wasn't* supported). However, now that we are going
to be adding field promotion support, it's important that it works
properly with joins, rebases, and try/finally.
So, instead of tracking properties through `VariableModel.properties`,
we assign each property its own promotion key, and include properties
in the `FlowModel.variableInfo`. This ensures that property promotion
will be properly handled by the existing logic for joins, rebases, and
try/finally, because that logic just treats the promotion keys as
opaque keys--it doesn't even know whether a given entry in
`FlowModel.variableInfo` represents a variable or a property access.
Note that changes to `use_of_nullable_value_test.dart` reflect
improvements to detection of when promotion via properties is being
attempted. Previously, when analyzing the code in these tests, a
context message was emitted explaining that promotion failed due to
field promotion not being supported, even though no attempt was made
to promote a field; this erroneous context message was codified into
the test expectations. Now that flow analysis no longer incorrectly
judges there to have been a field promotion attempt, we need to also
correct the test expectations.
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: I6c5cb1f6f4c98cbfa199baea24cd373408820996
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/250181
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@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>
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>
C compilers don't enforce nesting rules. `dart:ffi` was enforcing these
rules causing issues for binding to C libraries having looser packing
for nested structs than outer structs.
This CL completely removes the error from the analyzer and CFE.
(As an alternative we could have kept a hint/lint, but this might create
more noise than value.)
TEST=pkg/analyzer/test/src/diagnostics/packed_nesting_non_packed_test.dart
Closes: https://github.com/dart-lang/sdk/issues/46644
Change-Id: Iae2d5c885546f7799bc6dea2f8cd7dd508216a0c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247382
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Static class members could technically be mapped to a name with dots,
but in the early days of JSInterop we thought this was not necessary
since it could also be modeled as a top-level member or by adding
additional classes and exposing the member as a simple name on a deeper
class.
This invariant was assumed by DDC (which crashed if this was not the
case) and ignored by dart2js.
This change adds a static check to ensure both compilers act
consistenlty.
Fixes https://github.com/dart-lang/sdk/issues/27926
Change-Id: I20e59fbb75f0378a58ca88dc3910e079b4eeb7a3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247180
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Riley Porter <rileyporter@google.com>
This adds support for parsing `argument super` as its own expression
in augmentation libraries. This is not handled (correctly) by the
ast builders of analyzer and cfe yet.
Change-Id: Ibe67ad9daf56c82e8ec94f16d468e6b0d8f84d22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244922
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This allows the TypeDeclarationResolver to resolve generic type parameters that are seen as named type annotations.
There will likely be some work in the CFE and Analyzer to support actually doing that.
Change-Id: I223a630131a7d8c1d43719cadde53f682844b76a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244520
Auto-Submit: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Paul Berry