In theory, the order of resolving function literals during a type
inference stage shouldn't matter, because the only effect of visiting
a function literal during type inference is to capture writes, and
captured writes don't affect flow analysis in other function literals
due to the fact that a variable that's write captured anywhere is
already unpromotable in other closures.
However, to be on the safe side and to make the resolution process
deterministic, it seems better to resolve the function literals in
source order during each stage.
See https://github.com/dart-lang/language/issues/731 (improved
inference for fold etc.)
Change-Id: Iaecdfbd7e1eb89583a7d744371c40e2b904c7634
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241020
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
As Lasse pointed out in an internal review of the fix for
https://github.com/dart-lang/language/issues/731 (improved inference
for fold etc.), what I've implemented actually doesn't apply to all
closures, just to function literals. (Tearoffs of local functions are
also closures). This change adjusts the nomenclature to consistently
use the term "function literal" rather than "closure".
Change-Id: I64f255955494f7f881a081c32c9220c41cdc7990
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240861
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The purpose of horizontal inference is to allow the types of closure
parameters to be inferred based on the static type of other arguments
in the same invocation. When the closure parameter in question
already has an explicit type, there is no benefit, and there are
potential drawbacks (because horizontal inference could infer too
narrow a type).
This change includes the explicitness/implicitness of closure
parameter types in the dependency analysis for
https://github.com/dart-lang/language/issues/731 (improved inference
for fold etc.) so that we won't do horizontal inference when it's not
needed.
Change-Id: I33781877685867a8fcb40de54fc055f6348c21b2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240505
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Finalizer is not guaranteed to run if it becomes unreachable.
The test vm/dart/finalizer/finalizer_zone_run_gc_test incorrectly
assumed that Finalizer stored in a local variable is still reachable
after the last use of variable, but that is not guaranteed.
(Previously, async functions captured local variables into the
context and objects stored in local variables in async functions were
reachable even after variables become unused.
With the new async/await implementation, local variables in async
functions are handled in the same way as in ordinary functions and
not stored into the context, so this test started failing as
Finalizer was garbage collected and not executed.)
TEST=vm/dart/finalizer/finalizer_zone_run_gc_test
Change-Id: Id025556c68c5fc1cf08b06d44cb9d5bbd21dd916
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/239860
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This change addresses a corner case discovered during internal testing
of the fix for https://github.com/dart-lang/language/issues/731
(improved inference for fold etc.): if there is no order dependency
forcing us to do a round of horizontal inference between visiting
non-closure arguments and closure arguments, then it's important that
we *don't* do a round of horizontal inference before visiting the
closure, because there is a risk of inferring too narrow a type.
The new algorithm includes all the invocation arguments in dependency
analysis, and the dependency rules are structured such that
non-closure arguments always wind up in stage 1. If there is no
dependency between non-closure arguments and closure arguments, then
the closure arguments also wind up in stage 1, and no horizontal
inference occurs. If there is a dependency, then closure arguments
wind up in stage 2 or later, and horizontal inference occurs between
stages.
Change-Id: Ida0b28da211f63191c9c9c39e6004893617507bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240442
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
4 instances of the following issue: redundant get() call on smart pointer
Tested: Only through CI. There are no changes in behavior, all possible problems would be found through a compilation failure.
Change-Id: Ib11432baef83d3daebd800b365183e1ea6621136
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240540
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Oleh Prypin <oprypin@google.com>
This is an attempt to make the change to exception handling that you
mentioned in a previous CL. Let me know if this doesn't resolve the
problem you saw.
Also, this changes the number of responses and notifications found in a
poorly written test. I don't know whether it will change the behavior
that clients see, and if so whether that will cause problems, but it's
a little concerning. Interested to hear your thoughts.
Change-Id: I135e96bea5bd6e5e673dcdddd1b421e4c2011f89
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240647
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Since the null-safety test migration we've been generating both a .packages file
and a package_config.json file. This deletes the use of the old .packages file
and updates all references to use the new file.
Change-Id: Iecef64ac8ed8579338795ad5327765118d643236
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240650
Reviewed-by: Joshua Litt <joshualitt@google.com>
These loops introduce control flow that is more complex and harder to represent with Futures.
Tests are back to their state prior to the start of the async/await lowering changes. (The one failing test was already timing out)
Change-Id: Ia65f1a11bd73f2a30e7a186d69c34774c9e361a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240381
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This CL adds a test of the evaluation order in the case where a function
invocation `g(a)` or `r.g(a)` involves the invocation of a getter `g` that
returns a function object, and that function object is invoked with an
actual argument `a`.
The expectation in the test is that evaluation occurs left-to-right in
every case, with one exception: when `g` is a class instance getter (this
does not apply to extension instance getters) the actual argument list
is evaluated before the getter. This is the actually implemented behavior,
and the specification is being updated to specify this behavior
(cf. https://github.com/dart-lang/language/pull/2182).
------- Old description:
A piece of technical debt which has been around for several years is the
fact that the specified left-to-right evaluation order isn't implemented
everywhere.
In particular, with an ordinary invocation like `r.m(a)` where `m` is a
getter that returns a function, the argument is evaluated before the
getter is called, which is not a left-to-right ordering.
This CL adds a test (with 2 libraries) where the evaluation order is
detected, such that we can decide how to proceed.
Change-Id: Ia2619fe6b4c4cf4cec63bac9c9f834306bdefe52
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238903
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The way constants are printed using ast-to-text depend on which
libraries are available in the component. Because the incremental
compiler (by default) only returns the libraries that have been
recompiled, the first compilation contains more libraries than the
subsequent compilations. Using the same incremental compiler throughout
the incremental macro test made the output depend on the order in which
the tests were run, which in turn was dependent on the file order in
the directory.
To avoid this, and to support running individual tests with a stable
output, each test is now using its own increment compiler for all the
incremental steps within the test.
Closes https://github.com/dart-lang/sdk/issues/48558
Change-Id: I37946ed0f940b6644c5efb2b7d167b2a5717f2f3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240721
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
In some profiling, I saw that CodeChecker accounted for ~10% of the time
spent in `LibraryAnalyzer._computeVerifyErrors`.
The only errors which are reported any longer in CodeChecker are
pre-null safe errors, and the TOP_LEVEL_CYCLE error, which is moved to
resolution.
Change-Id: I9ad38a1c76490a95cbb8464465e37a07622b4f97
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240643
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
The test throws 1 million exceptions which can, especially in debug mode
can take very long.
This addresses flaky timeouts of this test in debug mode.
TEST=ci
Change-Id: Ibfa9108d49303d62aa4267c07e03499d0a831292
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240700
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Devon Carew