Since user @staticInterop types are erased to JavaScriptObject, they
should only be able to subtype other types that are :> JavaScriptObject,
which are just JSObject and JSAny. Eventually all the other JS types
will move to extension types and we can remove this check.
Change-Id: If56b6770e141238b583937880ca87496780c8fac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316865
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Previously, flow analysis used a hack to make it easy to generate "why
not promoted" messages when the user tried to promote a non-promotable
field: it treated all field accesses as stable for the purpose of
assigning SSA nodes, but avoided promoting non-promotable fields by
setting the `_Reference.isPromotable` flag to `false`. So, for
instance, in the following code, both subexpressions `c.i` got
assigned the same SSA node, even though there's no guarantee that
`C.x` will return the same value each time it's invoked.
class C {
int? get i => ...;
}
f(C c) {
if (c.i != null) {
var i = c.i; // Inferred type `int?`
}
}
This mostly worked, since the SSA node assigned by flow analysis is
only used for promotion, and promotion is disabled for non-promotable
fields. However, it broke when the field in question was used as the
target of a cascade, because fields within cascades always had their
`_Reference.isPromotable` flag set to `true` regardless of whether the
corresponding cascade target is promotable. For example:
class C {
D? get d => ...;
}
class D {
final E? _e;
...
}
class E {
m() { ... }
}
f(C c) {
(c.d)
.._e!.m() // OK; promotes _e
.._e.m(); // OK; _e is promoted now
(c.d)
.._e.m(); // OOPS, _e is still promoted; it shouldn't be
}
See
`tests/language/inference_update_2/cascaded_field_promotion_unstable_target_test.dart`
for a more detailed example.
This CL removes the hack; now, when a non-promotable property is
accessed more than once, flow analysis assignes a different SSA node
for each access. As a result, the `_Reference.isPromotable` is not
needed, because non-promotable fields simply never have the chance to
be promoted (since every field access gets a separate SSA node, so
type checking one field access has no effect on others).
To preserve the ability to generate "why not promoted" messages, the
`_PropertySsaNode` class now contains a `previousSsaNode` pointer,
which links together the separate SSA nodes allocated for
non-promotable properties, so that they form a linked list. The "why
not promoted" logic traverses this list to figure out which promotions
*would* have occurred if the property had been promotable.
In order to make it efficient to create this linked list, the
`SsaNode` class also had to acquire a `_nonPromotableProperties` map,
which records the SSA node that was allocated the last time each
property was accessed.
Fixes https://github.com/dart-lang/sdk/issues/52728.
Change-Id: I16a7b27f77c309bdccce86195a53398e32e8f75d
Bug: https://github.com/dart-lang/sdk/issues/52728
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318745
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Several changes are made:
- createDartExport now does not export methods that define type parameters.
- createStaticInteropMock adds conformance checks to make sure implementing
members can handle all possible values of a type parameter in an interop
member. An error is added to reduce confusion around this.
- Export creator now uses dart:js_interop_unsafe for a lot of its lowering
as the dart:js_util equivalents are buggy when it comes to calling exported
functions in JS with JS types.
- Small code changes are added to backends to handle the above changes.
Change-Id: Ie3b6b157930537267f270b60373b2b17e0a14344
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316141
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This CL introduces handling of promotions of the form `x is T` where
`x` has static type `X?`, `X` is a type variable, and `T` is
non-nullable. They are treated as an equivalent of `x == null || x is
T`, effectively resulting in the static type of `x` being `X & T` in
the promoted code.
Closes https://github.com/dart-lang/sdk/issues/52973
Change-Id: Ibfa6e32e14202651db09cfb4fbbdec864552b96a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316381
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
No functional change. By default, `_clone` re-uses the reachability of
`this`. The `reachable` argument allowed the caller to override that
default. However, the only call site that used it passed in
`this.reachable`, so there was no effect.
Change-Id: I2b08e29a724b35efc531f4bcfbc6ec4a2a2519d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317443
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The uses the #type handle to pass the DartType in the message rather
than using the toString() method which doesn't give the desired result.
Change-Id: Iac17507643a9932570d5975a106a3ededc03f58c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316585
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Since external APIs can only use primitives and JS types in static interop,
we should require that all type parameters on static interop APIs extend
another static interop type. This is the minimum required to ensure all
type parameters can be erased to JSValue. This only affects dart:js_interop
users and replaces the previous type parameter static error check.
Change-Id: Ia546874da73c808aa25deb8d54d581db783987df
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316140
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This language feature allows type promotion to apply to private final
fields, e.g.:
class C {
final int? _x;
C(this._x);
}
f(C c) {
if (c._x != null) {
print(c._x.abs()); // (1)
}
}
Previously the line marked (1) would have needed to be written
`print(c._x!.abs());`.
Note that to ensure soundness, there are certain restrictions:
- Public fields don't undergo promotion (because a public field might
be overridden by a class in some other library).
- Non-final fields don't undergo promotion (because a non-final field
might be modified as a side effect of code executed between the type
test and the field's usage).
- Fields that are forwarded to `noSuchMethod` in the same library
don't undergo promotion (because there's no guarantee that
`noSuchMethod` will return the same value on every invocation). For
example:
class C {
final int? _x;
C(this._x);
}
class D implements C {
@override
noSuchMethod(...) => ...;
}
f(C c) {
if (c._x != null) {
print(c._x.abs()); // ERROR: `c._x` might dispatch to
// `D.noSuchMethod`, in which case there's
// no guarantee that it will return a
// non-null value the second time it's
// invoked.
}
}
- If two classes define fields or getters of the same name, and
promotion is not permitted for one of them, then it isn't permitted
for the other. This is because there might be a class in some other
library that's a subclass of both classes, causing a reference to
one field or getter to dispatch to the other. For example:
class C {
final int? _x;
C(this._x);
}
class D {
int? get _x => ...;
}
f(C c) {
if (c._x != null) {
print(c._x.abs()); // ERROR: `c._x` might dispatch to `D._x`
// (e.g. because some library might declare
// `class E extends D implements C`), in
// which case there's no guarantee that it
// will return a non-null value the second
// time it's invoked.
}
}
Change-Id: Ib9183581aa0194377e38ab70d37c3e9f0bb57a75
Bug: https://github.com/dart-lang/language/issues/2020
Tested: TAP global presubmit
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/314600
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is not the flag you're looking for.
The 'extension-types' flag was used for an early experiment that is
not directly related to the Extension Types feature currently being
developed. The current feature uses the 'inline-class' flag.
Change-Id: Icbb6c3828c41e743e726161b17da4c7784a2c677
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316380
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds parser support for the optional 'const' keyword in extension
type declaration. The token is passed on through the endPrimaryConstructor
listener call since it is used to make the primary constructor constant.
Change-Id: I518a8e397fb62272002c424e7b69affe6123f4af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316221
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Previously, in the "mini-ast" pseudo-language for shared flow analysis
and type analysis unit testing, there were two separate functions to
create a rest pattern (`...`):
- `listPatternRestElement` for creating a rest pattern for use in a
list pattern
- `mapPatternRestElement` for creating a rest pattern for use in a map
pattern
The latter is not allowed in Dart, but it's supported to allow for
better error recovery.
But having two functions wasn't necessary--the two functions did
exactly the same thing.
This CL simplifies things so that there is just a single function,
`restPattern`. It also renames the underlying representation class
from `RestPatternElement` to `RestPattern`, to match the nomenclature
in the patterns spec document.
Change-Id: Iecfe8c86f49161e0657cdab44f000f47c0e3c212
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315520
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Tested: CQ
Change-Id: I16210697b47dd85aec8743b457e773b044cab81f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316200
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
This change adds the functions `mapLiteral` and `mapEntry` to the
"mini-ast" representation used for unit testing shared flow analysis
and type analysis logic. These can be used to model map literals with
explicit type arguments. Set/map literals without explicit type
arguments are not supported yet.
These functions replace the old `inContextMapEntry` method, which was
an alternative way of testing the type analysis behavior of map
literal entries (and was not yet being used). The new approach is
better in that it allows the test cases to follow the structure of
actual Dart code (map entries inside map literals) rather than just
testing map entries in isolation.
Change-Id: I4bfd31b8fb2865f3d0892da0a47ee0bdacaf9250
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315225
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These are intended to be syntactic and not semantic in meaning, so I think has* is a better name.
Change-Id: Ia2a8a276c1057bde913eb755cc1a7a559d953774
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315960
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
When using the "mini-ast" pseudo-language to write unit tests for the
flow analysis and type analysis logic in the `_fe_analyzer_shared`
package, it is no longer necessary to use `.expr` to turn a `Var` into
an `Expression`; this now happens automatically. The way this works
under the hood is that the `Var` and `Expression` classes implement
the `ProtoExpression` interface; constructs that expect expressions
are declared with input parameters of type `ProtoExpression`, and they
automatically convert to `Expression`s when necessary.
Change-Id: I85c493145c3fc41a5296c1807cd63fe1401672db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315247
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I did not change the content of the functions, except the following:
* modernized some variable declarations with `var`.
* added periods to the end of comments.
* privatized most methods.
Work towards https://github.com/dart-lang/sdk/issues/50702
Change-Id: I4d63d3ee847316b58fa76c12558767c0825027a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315243
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
the types phase.
Also seales the Code types hierarchy to block users from attempting to
create their own subclasses.
Bug: https://github.com/dart-lang/language/issues/3211
Change-Id: I51ebdfdad6e1fba3c19ef91f25e238730e98e740
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/314821
Auto-Submit: Jake Macdonald <jakemac@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Previously, when using the "mini-ast" pseudo-language to write unit
tests for the flow analysis and type analysis logic in the
`_fe_analyzer_shared` package, it was possible to call `.pattern` on
any arbitrary expression, creating a constant pattern containing the
expression. This didn't make sense--only constant expressions can be
used as the basis for constant patterns.
With this change, `.pattern` is only available on the various forms of
constant expressions supported by the "mini-ast" pseudo-language
(currently: integer literals, the `null` literal, and placeholder
expressions created using the `expr` function).
Change-Id: I0d87c66bdb8e636615b20bbb6207c38d78d0d2dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315245
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
In several flow analysis tests we need to model an expression with two
subexpressions, where the type of the overall expression is the same
as the type of the second subexpression.
Previously we did this using `ProtoStatement.thenExpr`, which created
a magic compound expression consisting of an expression (or statement)
followed by a second expression. This was too general, since it
allowed modelling code that would not be possible in Dart.
This CL replaces uses of `ProtoStatement.thenExpr` with a function
`second`, which models a Dart function defined this way:
T second(dynamic x, T y) => y;
This has two advantages:
- The tests are now modelling code that could actually exist in the
real world, rather than modelling pseudo-expressions that are not
actually possible to write in Dart.
- It prepares for a follow-up CL in which I'll be unifying the
representation of patterns and expressions in the flow analysis
tests; eliminating `ProtoStatement.thenExpr` will prevent a conflict
between it and `PossiblyGuardedPattern.thenExpr`.
With this change, two tests had to be deleted, because the conditions
they were testing could no longer be expressed:
- `for_conditionBegin() handles not-yet-seen variables`
- `whileStatement_conditionBegin() handles not-yet-seen variables`
This is ok, because these tests were designed to verify correct
behavior in the circumstance where the client forgets to declare a
variable. This circumstance no longer arises, because the
`_FlowAnalysisImpl` constructor detects undeclared variables and
generates synthetic declarations for them.
Change-Id: I19275ba0b7fa143ce7051bf14d0d4c6f57a4ab8e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315244
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
The following functions, which are used to create constructs in the
"mini-ast" pseudo-language to write unit tests for shared flow
analysis and type analysis logic, now have a return type of
`Expression` rather than `Statement`:
- checkAssigned
- checkUnassigned
- getSsaNodes
- implicitThis_whyNotPromoted an expression
This allows them to be used either where an expression is exprected or
where a statement is expected, which should give us the ability to
write some tests that are not possible (or very difficult) to write
today.
Change-Id: Ie50e82ad05dc88182b59c99c11ffaac41515ebb9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315460
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
When using the "mini-ast" pseudo-language to write unit tests for the
flow analysis and type analysis logic in the `_fe_analyzer_shared`
package, it is no longer necessary to use `.switchCase` to turn a
`Pattern` (or a `GuardedPattern`) into a `SwitchHead`; this now
happens automatically. The way this works under the hood is that the
`PossiblyGuardedPattern`, and `SwitchHead` classes implement the
`ProtoSwitchHead` interface; constructs that expect switch heads are
declared with input parameters of type `ProtoSwitchHead`, and they
automatically convert to switch heads when necessary.
Change-Id: Ic16264fc52ffff08bf0e0cc72db064a6da63eda5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315180
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When using the "mini-ast" pseudo-language to write unit tests for the
flow analysis and type analysis logic in the `_fe_analyzer_shared`
package, it is no longer necessary to use `.asCollectionElement` to
turn an expression into a collection element; this now happens
automatically. The way this works under the hood is that both the
`CollectionElement` and `Expression` classes mix in the
`ProtoCollectionElement` mixin; constructs that expect collection
elements are declared with input parameters of type
`ProtoCollectionElement`, and they automatically convert expressions
to collection elements when necessary.
Also, instead of using `.inContextElementType` to establish the
appropriate context when testing a collection element, the tests not
simply create a `listLiteral` of the appropriate type, containing the
appropriate collection elements. This makes the unit tests much more
similar to the way actual Dart code is written in the wild, and makes
the test infrastructure more closely mirror the way types are analyzed
by the analyzer and CFE.
Change-Id: Ib628ff12caa84254df069308ae3a25061377db29
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/314141
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
- Rename declarationOf to typeDeclarationOf.
- Add declarationOf api for general declarations.
- Tighten the type of typeDeclarationOf in the final phase to avoid unnecessary
casts in user code.
- Refactor message handling a bit to unify the error handling.
Bug: https://github.com/dart-lang/language/issues/3216
Change-Id: Ia61da19374abec77853d37e110a08f7dfe0d3b10
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/314280
Commit-Queue: Jake Macdonald <jakemac@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
The purpose of the wasm_js_compatibility target is to facilitate experiments with a JS compatibility mode for Dart2Wasm. Initially, we're just going to focus on typed data, but this will give us a place to experiment with moving List and String to JS as well.
In addition, someday down the road we hope to experiment with two additional compatibility changes:
1) Exclusively using double for all Dart numbers
2) Allowing undefined to flow as null.
The two major benefits of this approach are:
1) Much faster JS interop
2) To make it easier to bring up Dart2JS applications on Dart2Wasm
The only downside will be access overhead on the Wasm side, but the JS builtins proposal could potentially bring us close to parity with Wasm builtins someday.
Tested: Wasm specific trivial refactor.
Change-Id: I2c09426b6999507c1de6e584e9bc7072a088bda9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313240
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: William Hesse <whesse@google.com>
In the following code, it's not safe for the field `C._f` to undergo
type promotion, because a variable with static type `C` might have
type `D` at runtime, in which case `C._f` will get dispatched to
`noSuchMethod`, which is not guaranteed to return a stable result.
class C {
final int? _f;
}
class D implements C {
noSuchMethod(_) => ...;
}
foo(C c) {
if (c._f != null) {
print(c._f + 1); // UNSAFE!
}
}
Therefore, in order to determine which fields are promotable, the
implementations need to analyze enough of the class hierarchy to
figure out which field accesses might get dispatched to
`noSuchMethod`.
Currently, the CFE does this by following its usual algorithm for
generating `noSuchMethod` forwarders before trying to determine which
fields are promotable. The analyzer, on the other hand, doesn't have
an algorithm for generating `noSuchMethod` forwarders (since it
doesn't implement execution semantics); so instead it has its own
logic to figure out when a `noSuchMethod` forwarder is needed for a
field, and disable promotion for that field.
But there's a chicken-and-egg problem in the CFE: the CFE needs to
determine which fields are promotable before doing top-level inference
(since the initializers of top-level fields might make use of field
promotion, affecting their inferred types--see #50522). But it doesn't
decide where `noSuchMethod` forwarders are needed until after
top-level inference (because the same phase that generates
`noSuchMethod` forwarders also generates forwarders that do runtime
covariant type-checking, and so it has to run after all top level
types have been inferred).
To fix the chicken-and-egg problem, I plan to rework the CFE so that
it uses the same algorithm as the analyzer to determine which fields
are promotable. This CL makes a first step towards that goal, by
reworking the analyzer's field promotability algorithm into a form
where it can be shared with the CFE, and moving it to
`package:_fe_analyzer_shared`. Since this required a fairly
substantial rewrite, I went ahead and fixed#52938 in the process.
Fixes#52938.
Change-Id: I9e68f51b3ea9a967f55f15bdc445cc1c0efdabdd
Bug: https://github.com/dart-lang/sdk/issues/52938
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313293
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Each phase now only has a single interface, instead of several of them. This
reduces the number of classes dramatically and also reduces the number of
objects actually sent over the wire.
It also means fewer things to name and a less polluted namespace.
Change-Id: Ib84b76ac4c0a04abfac5fd5650a228046b1bf1d4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313721
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
To be removed after Dart SDK 3.1 is published, and the analyzer
SDK constraints updated.
See
https://dart-review.googlesource.com/c/sdk/+/254903
Change-Id: I2c3321d991cd3e123f08c5a360487362be16f258
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313920
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
While working on some other changes to flow analysis, I discovered
that this particular behaviour wasn't unit tested.
Change-Id: Ia9b27672c62177ffed80d4143f33c5b764ac7bbe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313242
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
When using the "mini-ast" pseudo-language to write unit tests for the
flow analysis and type analysis logic in the `_fe_analyzer_shared`, it
is no longer necessary to use `.stmt` to turn an expression into an
expression statement; this now happens automatically. The way this
works under the hood is that both the `Statement` and `Expression`
classes mix in the `ProtoStatement` mixin; constructs that expect
statements are declared with input parameters of type
`ProtoStatement`, and they automatically convert expressions to
statements when necessary.
Also, the functions `checkNotPromoted`, `checkPromoted`,
`checkReachable`, `localFunction` now have a return type of
`Expression` rather than `Statement`. This allows them to be used
either where an expression is exprected or where a statement is
expected, which should give us the ability to write some tests that
are not possible (or very difficult) to write today.
Change-Id: I9f7ad5b15bcf8ccfccafc6985e0163b550c5ad1c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313680
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The assertion in the `_FlowAnalysisImpl` constructor was unnecessary
because it was checking that all variables that are reported to
`AssignedVariables` as read or written must also be reported as
declared. This is already checked by assertions in
`AssignedVariables.finish`, which is called by the `_FlowAnalysisImpl`
constructor.
I've added tests to `assigned_variables_test.dart` to confirm that
these assertions work, and I've also cleaned up the assertions a bit,
eliminating some redundancy and ensuring that in the event of a
failure the assertion failure message will be comprehensible.
Change-Id: Ife827c91d944707f093f4cb8421385f5355d11fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313140
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This method caused invalid exhaustiveness checking by seeing
record types as related based solely on the structure.
The original purpose of the methods has been removed in the mean time
by the change to restrict the created spaces by the matched value
type.
Closes#52800
Change-Id: I8fb581374a4813dc63261d9e1354c4eea94f212c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312982
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
These are intended to be applied by annotating a library directive.
Note that some parameter types had to be widened since `Library` is not a subtype of `Declaration`. Ultimately I think that is fine though.
Bug:https://github.com/dart-lang/language/issues/2839
Change-Id: Ia1311c8aea729f2bd8b76173ce4c7595a6a37a42
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312140
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Allows you to ask for the types in a library in the declarations phase, and all
the top level declarations in the definitions phase.
Bug: https://github.com/dart-lang/language/issues/2839
Change-Id: If0f8fb777fd8a006d686d457cf5d5ca11fcca9ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311900
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
