The function types are given an empty name in that case. Those types
are further discarded and can have any intermediary name.
Part of https://github.com/dart-lang/sdk/issues/48919
Change-Id: I57d223ee7914d0227baa3a4ef5733bb8055fa2c3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244240
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
As part of the implementation of
https://github.com/dart-lang/language/issues/731 (improved inference
for fold etc.), I expanded the front end's type inference logic so
that instead of just having a downward phase and an upward phase, it
could have 3 or more phases. The function that previously did
downward inference became repurposed to do "partial inference" (which
could either be the first, downward stage, or a later, horizontal
stage). However, I failed to generalize the logic that prevents types
assigned by one inference stage from being refined by later
stages--previously this logic was only needed for upward inference,
but now it's needed for horizontal inference stages as well. (This
logic is needed because of Dart's "runtime checked covariance"
behavior--it means that we want to stick with the type from downward
inference, even if a later horizontal inference stage is able to find
a more precise type, because that more precise type may lead to
runtime failures).
As part of this change I've re-architected the inference methods so
that they are responsible for creating and returning the list of
inferred types. This makes the inference logic more similar between
the front end and analyzer, and is easier to read IMHO. The total
number of list allocations is the same as before.
Change-Id: I19bfcede9c2968e50f110b571164549f16495217
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243707
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The front end desugars extension methods by inserting a synthetic
`this` argument before all other arguments. But this synthetic
argument isn't included in the `formalTypes` and `actualTypes` arrays.
So when recording a value into
`_DeferredParamInfo.evaluationOrderIndex` we may need to subtract 1 in
order to ensure that later logic will find the correct argument.
Fixes a corner case of https://github.com/dart-lang/language/issues/731.
Change-Id: Idbf136195e40555199f7c5b61a575a430f6ec6bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243854
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This adds a --platform= option to dart2wasm to read the SDK libraries
from that dill file instead of compiling them from source every time.
If the option is not given, the SDK libraries are compiled, like before.
Also adds a "dart2wasm" build target, which will build the dart2wasm
platform dill and compile dart2wasm to two AOT snapshots (with and
without asserts). The dart2wasm scripts in sdk/bin are updated to run
via these snapshots and use this platform dill.
This speeds up test runs for the dart2wasm-hostasserts-linux-x64-d8
configuration by approximately 45x.
Change-Id: If2c7750a6eb39725310745f887792784d0dfc583
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243624
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
This option traces in which steps time is spent when running a suite.
On my machine for instance I get these results on a run ofstrong and
weak suites:
$ out/ReleaseX64/dart --enable-asserts pkg/front_end/test/fasta/strong_suite.dart -DsemiFuzz=true --traceStepTiming
Running suite strong...
[ 02:58 | 100.0% | + 571 | - 0 ]: strong/value_class/value_mixin_error
check errors: 0:00:00.156828 ms
stress constant evaluator: 0:00:00.269382 ms
print: 0:00:00.439196 ms
typeCheck: 0:00:02.575744 ms
match expectations: 0:00:04.869435 ms
verify: 0:00:04.951524 ms
compile: 0:00:18.307246 ms
transform component: 0:00:22.121665 ms
semifuzz: 0:00:59.717862 ms
write .dill: 0:01:05.066461 ms
run: 0:01:15.028423 ms
$ out/ReleaseX64/dart --enable-asserts pkg/front_end/test/fasta/weak_suite.dart -DsemiFuzz=true --traceStepTiming
Running suite weak...
[ 10:11 | 100.0% | + 2225 | - 0 ]: weak/variance/unconstrained_inference
check errors: 0:00:00.506722 ms
stress constant evaluator: 0:00:00.759073 ms
print: 0:00:01.293962 ms
typeCheck: 0:00:09.974299 ms
match expectations: 0:00:16.386842 ms
verify: 0:00:17.585821 ms
compile: 0:01:01.966016 ms
transform component: 0:01:23.560216 ms
semifuzz: 0:02:50.969460 ms
write .dill: 0:04:08.087519 ms
run: 0:05:17.911549 ms
In both cases writing dill and running takes quite a while, and
interesting writing the dill is almost as slow as running it.
Change-Id: Ie528e8f7e8a493e17e40a7235b456cc75381ca61
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242874
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This comment was meant as a note to myself as part of the
implementation of https://dart-review.googlesource.com/c/sdk/+/243002.
I accidentally forgot to delete it even though I added the necessary
test cases (`testLaterUnnamedParameterDependsOnNamedParameter` and
`testEarlierNamedParameterDependsOnUnnamedParameter` in
`tests/language/inference_update_1/horizontal_inference_enabled_test.dart`).
Change-Id: I80f0c63fa19256a4cd3fa657578124fa9bddf6d4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243845
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
- Wrap returns in Future.value to ensure the returned Future has the async function's return type.
- Skip any function that has try/catch/finally as these introduce more complex control flow. (Might be able to convert these using an onError callback in the future).
- Don't assume futureValueType since CFE might not populate it in Kernel when syntax is incorrect.
Change-Id: Ice3954da52a10a74f93b0adc6409a2d98e13cb3b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241260
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
This change allows function literals in invocations to be inferred in
dependency order. For example, given the following code:
U f<T, U>(T Function() g, U Function(T) h) => h(g());
test() {
var x = f(() => 0, (y) => [y]);
}
The function literal `() => 0` is inferred first, causing the type
parameter `T` to be assigned the type `int`. Then, `(y) => [x]` is
inferred with the benefit of this type assignment, so `y` gets the
type `int`, and consequently, `U` gets assigned the type `List<int>`.
This completes the support for
https://github.com/dart-lang/language/issues/731 (improved inference
for fold etc.)
Change-Id: I48c22693720a1cc8bbf435643e863834e07f02b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243002
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This might be a compile-time error but it should at least not create
an Instantiation on a potentially nullable expression.
In response to https://github.com/dart-lang/sdk/issues/48323
Change-Id: I6682ddbb8db82623ac7bf4ecf37f8535377f4ca0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242869
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
When a function literal is wrapped in parentheses, it shouldn't affect
how it interacts with type inference. This change ensures that
parenthesized function literals are treated the same as
unparenthesized ones by the logic that supports
https://github.com/dart-lang/language/issues/731 (improved inference
for fold etc.)
Change-Id: I672787a31addbfe3f3282b6e638e00b693eea46f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243000
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In order to address https://github.com/dart-lang/language/issues/731
(improved type inference for `fold` etc.) we're going to need to
sometimes defer analysis of invocation arguments that are closures, so
that closure parameters can have their types inferred based on other
parameters. To avoid annoying the user with inconsistent behaviors,
we defer analysis of closures in all circumstances, even if it's not
necessary to do so for type inference purposes.
This has a minor user-visible effect: if an invocation contains some
closures and some non-closures, any demotions that happen due to write
captures in the closures are postponed until the end of the
invocation; this means that the write-captured variables remain
promoted for other invocation arguments, even if those arguments
appear after the closure. This is safe because there is no way for
the closure to be called until after all of the other invocation
arguments are evaluated. See the language tests in
tests/language/inference_update_1/write_capture_deferral_enabled_test.dart
for details.
Note that this change only has an effect when the experimental feature
`inference-update-1` is enabled.
Change-Id: If7bb38e361755180c033ecb2108fc4fffa7570b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241864
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In 64a169ec7e an incremental test -
import_package_by_file_uri - was added, which imports a file both via
its "file uri" and via its "package uri", resulting in "the same"
library existing twice. This also means that two libraries has the same
"file uri" which is what we search for when leak testing, meaning that
our weekly leak test failed.
This CL skips this test for leak testing as it by design will trigger
the situation the leak test looks for.
Change-Id: I85a9ac4e3f4dc19203955dbb1724402196c78fdf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242840
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Recompiling changes the given error from
```
Can't create typedef from non-function type.
```
to
```
Couldn't find constructor 'Bar'.
```
which does seem to make more sense when the code is `new Bar<int>()`.
http://dartbug.com/48897
Change-Id: I4d025fc2ec96f530b4d4b00aec18fab6a781710f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242543
Reviewed-by: Johnni Winther <johnniwinther@google.com>
VariableDeclaration.type changes from InterfaceType(String?) to
FutureOrType(FutureOr<String>?) and the async transformation goes
from calling _completeWithNoFutureOnAsyncReturn to calling
_completeOnAsyncReturn upon recompilation with no change.
http://dartbug.com/48891
Change-Id: Ie28bcc37739742ccb33c033d7c7edff3f5b921e3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242443
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This demonstrates two things:
1) fileOffset changes because it goes to point from one file to another
-- it doesn't specify the file of course --- and Constants shouldn't
have fileOffsets in them at all.
2) Constant pointing to a type that points to a Typedef (which it
shouldn't) which then again also changes upon recompilation.
http://dartbug.com/48890
Change-Id: If5f7ce56b3e95d92fc0c060002842325f9136146
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242441
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This fixes an issue where VM would run the async* generator after a
`yield` / `yield*` even though the subscription may be paused or
cancelled.
Furthermore this fixes an issue where `StackTrace.current` used
in async* generator crashes VM and/or produces truncated stack
trace.
This fixes the following existing tests that were failing before:
* co19/Language/Statements/Yield_and_Yield_Each/Yield_Each/execution_async_t08
* co19/Language/Statements/Yield_and_Yield_Each/Yield_Each/execution_async_t09
* co19/Language/Statements/Yield_and_Yield_Each/Yield_Each/execution_async_t10
* language/async_star/async_star_cancel_test
* language/async_star/pause_test
New in reland: Allow the generator to to cause cancelling it's own consumer.
This addresses the issue of original revert
-> see https://github.com/flutter/flutter/issues/101514
Issue https://github.com/flutter/flutter/issues/100441
Issue https://github.com/dart-lang/sdk/issues/48695
Issue https://github.com/dart-lang/sdk/issues/34775
TEST=vm/dart{,_2}/causal_stacks/flutter_regress_100441_test
Change-Id: I091b7159d59ea15fc31162b4b6b17260d523d7cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242400
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Previously the tear-offs created for the origin constructors were not
replaced with the tear-offs created for the patch constructors - as is
normally done for the constructors themselves. This lead the tear-offs
to refer to unlowered code, breaking dart2js.
Closes https://github.com/dart-lang/sdk/issues/48776
Change-Id: I1cb09c07bb2ac7fffb81acd31547ee96e7ecdc64
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242284
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Currently initializers (in, say, a Constructor) is included in the
outline if it is not null. Null values are explicitly added only when
building the bodies.
This has the unfortunate effect of initializers copied in the outline
phase (e.g. for mixins) not including the null initializer. If, however,
later recompiling (even without changes, and if the split is correct)
suddenly an initializer changes.
This CL fixes the issue by initializing to null in the outline phase.
Change-Id: I1269da25ab893d4610cf2dbb4fbfdbd5697e5323
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242282
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Add `toText` to both Reference and CanonicalName.
Change how CanonicalNames are printed through `text_util.dart` to be
more aligned with how the corresponding node would be printed had
it existed (and the CanonicalName thus normally not been used for
printing).
Add a test for (some definition of) common cases where printing should
be the same wherther done though the node, the reference or the
canonical name.
Fix usage of toStringInternal in the constant evaluator (though only
in use through an experiment) and add a test that showed that the
previous output was bad and the new isn't (at least in this case).
Change-Id: I10cbc1a542c7d8b079e0510bbd5eb5173b2e7563
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242102
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL follows up on
https://dart-review.googlesource.com/c/sdk/+/239668
where parts was left non-working.
Now part files are ignored (i.e. we don't try to split it and add
imports/exports where it isn't supported), and the part declaration(s)
is(/are) kept only in the "main" file.
Change-Id: I63fa8ac8fcf173234a8162297f1c5eb1d94b00da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241961
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
From a high level, the experimental invalidation works by comparing the
before and after version of a changed file, checking if the (textual)
outline has changed. If it hasn't it can go ahead with the experimental
invalidation, only recompiling the changed file/library.
Turns out, though, that if a *part* is changed in a
textual-outline-changing-way it is *not* detected, i.e. one can (in a
part) make a change that isn't compatible with (safe) experimental
invalidation, yet experimental invalidation will still be in effect.
A similar issue exists if a mixin is declared in a part file.
This CL fixes the issue.
Change-Id: I150184885164229e6a9e0a6fa86f7c330b3bc3f3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241969
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
In order to implement https://github.com/dart-lang/language/issues/731
(improved inference for fold etc.), we'll need to gradually accumulate
type constraints as we evaluate arguments, and periodically re-do
inference; we can't just accumulate all the formal types and actual
types and run them through an inference process at the end.
This change moves us a step toward that eventuality, by accumulating
type constraints after type inference visits each argument, rather
than all at once after all arguments have been visited. The total
amount of work done is unchanged.
Change-Id: I91ed0529cd3142afe4153cac8c25bce3c20f137d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241800
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In order to support https://github.com/dart-lang/language/issues/731
(improved inference for fold etc.) I'm going to need to add logic to
_inferInvocation to postpone type analysis of arguments that are
function expressions. To avoid having to code up this logic twice, it
will be helpful to have both named and unnamed arguments handled by
the same chunk of code.
In particular, this change unifies the computation of
inferredFormalType, the recursive call to inferExpression, the logic
for hoisting, and the update of the local variables identicalInfo,
formalTypes, and actualTypes. We pay a small price by having to have
multiple `if (isExpression)` checks, but these should be very fast.
Change-Id: I095a7eac84237eeb878cc3dd86e76a6a871f31d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241041
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This adds support for adding a no-name constructor using macros to a
class with no explicit constructor.
Change-Id: I4b614b74fe141ccb4797ace8d73c3ce2869f3826
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241750
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
If importing the same file both by package-uri and file-uri it becomes
two different libraries in the compiler. They both have the same file
uri though.
When invalidating such a file by file uri they will both be invalidated.
When having experimental invalidation enabled it will - for each of
those invalidated libraries - get the source, compare it to the current
on-disk source, and - if the outline hasn't changed - remove the old
source to avoid having something wrong in memory. When trying to process
the second version of the file the old source has been removed and we
thus will crash if using a bang on the output from the uriToSource
lookup.
This CL avoids the crash by postponing the removal of the old source
until we're sure we'll return successfully. This is also more correct
in general as we might otherwise remove sources where we're (for later
reasons) going to bail out.
Change-Id: If5d767764a958b2dbb09cc011745e13e572038a5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241745
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Adds an experimental `@trustTypes` annotation which can be used during
migration to static interop to preserve the older semantics for JS interop.
Change-Id: Ic00a6c968b15f8c8f5d0840b82db5a6670eaf0eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241362
Reviewed-by: Riley Porter <rileyporter@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Hoisting function literals isn't necessary because evaluating a
function literal doesn't have any side effects.
This paves the way for adding support for
https://github.com/dart-lang/language/issues/731 (improved inference
for fold etc.), which will require deferring type analysis of function
literals. By not hoisting them, we will be able to avoid a lot of
unnecessary complexity in the logic to defer them.
Change-Id: I0a49aa9f769f0506569e6029a3697898308600c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241007
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This updates the analysis helpers to add a test for the `map().toList()`
problem addressed in https://dart-review.googlesource.com/c/sdk/+/241605
Included in the CL is the addition of the 'analyze.dart' tools, which
can be used for advanced code searches. This was used to find the
occurences of `map().toList()`.
Change-Id: I6e9da282e37fde4534ed5e308260f092779d0750
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241744
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Expressions like
List<VariableDeclaration> variables = ...
List<Expression> reads = variables.map((v) => VariableGet(v)).toList()
don't get the intended type argument `<Expression>` through inference,
but instead the type inferred from the return type of the closure, in
this case `<VariableGet>`.
This causes problems when used with the AST which assumes that
expressions are interchangeable wherever they are used, and is likely
the cause of https://github.com/flutter/flutter/issues/102077 .
This CL adds an explicit type argument in these cases.
TEST=general/infer_map
Change-Id: I0bcae21f06c54f290dc20686b0d84c065d8ea04c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241605
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Previously, the front end would perform downwards and upwards
inference using separate TypeConstraintGatherer objects. This meant
that any constraint gathering work performed during downwards
inference had to be repeated during upwards inference.
This change avoids the extra work by using a single
TypeConstraintGatherer object for both downwards and upwards
inference.
This should help pave the way to implementing support for
https://github.com/dart-lang/language/issues/731 (improved inference
for fold etc.)
Change-Id: Ib4031ab1397d6a8547a705f386632de0e4dd1a2b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241120
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Only the 'fileUri' property was used, so we pass it directly instead.
Change-Id: I7b47f18f7ebc2c50036c5202e469caad4ba35897
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241009
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
