This configuration is used by some of our benchmarking bots
but it wasn't tested explicitly here.
Change-Id: I913b54863c10ededeff179b7cd1adee1577470a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242960
Reviewed-by: Jonas Termansen <sortie@google.com>
Commit-Queue: Jonas Termansen <sortie@google.com>
For some reason, we launched Safari from a file, which since macOS 10.14
requires the user to confirm the operation in a modal dialog which
caused timeouts.
* Removed unused http test driver port option.
* Added some basic tests for test.py's browser interactions.
Bug: b/208186791
Change-Id: I070529148d37bf312f219c576abca3da972f73e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204202
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
The new implementation moves away from desugaring of async
functions on kernel AST, state machine generated in the flow graph and
capturing all local variables in the context.
Instead, async/await is implemented using a few stubs
(InitSuspendableFunction, Suspend, Resume, Return and
AsyncExceptionHandler). The stubs are implemented in a
platform-independent way using (macro-)assembler helpers.
When suspending a function, its frame is copied into a SuspendState
object, and when resuming a function it is copied back onto the stack.
No extra code is generated for accessing local variables.
Callback closures are created lazily on the first await.
Design doc: go/compact-async-await.
Part 1 (kernel): https://dart-review.googlesource.com/c/sdk/+/241842
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/48378
Change-Id: Ibad757035b7cc438ebdff80b460728b1d3eff1f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242000
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Isolate may be entering or leaving the group while a scavenge is running and using the active mutator count to decide the size of the next to-space. A stale value seen by the scavenger only has performance implications rather than correctness implications, which will get fixed at the next scavenge.
TEST=iso-stress-linux
Bug: https://github.com/dart-lang/sdk/issues/48921
Change-Id: I171e5a460eadba3db6659dccda29c863549d27ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242925
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
No code actually relies on it being there.
This saves ~1kb of snapshot size on a large Flutter application.
Related to https://github.com/dart-lang/sdk/issues/48910
TEST=ci
Change-Id: I03cf8811f39fc8882f7c650a79f01d350b520e5d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242863
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
We would add function itself to the invocation dispatcher cache
if the function itself can handle dynamic invocation.
However GetInvocationDispatcher will never be able to find this
entry because it looks specifically for functions with
kDynamicInvocationForwarder kind.
This lead us to add many duplicated entries to the cache.
The logic in the resolver does not actually need the cache to contain
the function because it falls through to lookup using unmangled name.
For a large Flutter application: before this change invocation dispatcher caches were contributing 129244 bytes to the snapshot, after this change they contribute 7764 bytes.
Fixes https://github.com/dart-lang/sdk/issues/48914
TEST=ci
Change-Id: I639d268e75fd43d2f4f0b1ea5a7873ba169f9d66
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242862
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Some JS functionality is only exposed through operators, such as
implicit type conversions and BigInt arithmetic. Other than requiring
some minor additions for the exponentiation (`**`) operator, supporting
these through `dart:js_util` is trivial.
Change-Id: I010674303e4f99b42d43b73095de69b8ddcdeb47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242680
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This field is only used only by vm-service (including
hot reload and debugging), Kernel loading and mirrors.
So drop it to prevent putting it into the AOT snapshot.
Saves at 125Kb of snapshot size on large Flutter app.
Related to https://github.com/dart-lang/sdk/issues/48910
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-linux-product-x64-try
Change-Id: Id7c47496e87482d462c2b318307f617d48758ad1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242864
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This cleans up the temporary splitting of ParameterStructure into two
libraries.
Change-Id: I475ed3dfc67da81c1f4bcc85c5660095d5457374
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242781
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
These libraries are a cycle.
Change-Id: I0d1145876dd4dc341c426de9dafd4a2ff817fd81
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242780
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
In the definition of `_computeExplicitlyTypedParameterSet`, I
accidentally nested the declaration of `unnamedParameterIndex` inside
the `for` loop, defeating the increment and causing all parameters to
be considered to have index 0.
I've included a test case that would have caught the mistake.
Bug: https://github.com/dart-lang/language/issues/731
Change-Id: I0cd0e1e5b481313150e495d370af2477253d6637
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242741
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@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>
These tests exercise the "deferred type inference of function
literals" part of https://github.com/dart-lang/language/issues/731
(improved inference for fold etc.) for super-constructor invocations
and redirecting constructor invocations, both of which have their own
code paths in the analyzer.
Change-Id: I6877ac3c07a3cca31550ba74d941d250c8410cfd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241987
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
- create a small 'facade' interface CommonElementsForDartTypes so that common/elements.dart can implement this interface to break the cycle between common/elements.dart and elements/types.dart
- Separate the tagging enums used into serialization into a separate 'tags.dart' library.
- Scattered hints to help the migration tool.
Change-Id: I8dbb993ebeb85f240392bafa53e4cc235825f63e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242506
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
When unconditionally adding in each byte, this causes the last-byte marker to appear in a constant position. The correction factor for each exit branch is the same, allowing it to be folded into subsequent load offsets.
Startup.ReadProgramSnapshot(StartupTime): on a Moto x4
arm32 40456 -> 37414 us (-7.52%)
arm64c 46012 -> 44457 us (-3.38%)
TEST=ci
Change-Id: Ie7fd69504f9d9edf0c17458281a3750931d7d97b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242392
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
These will be flagged by the next linter release which updates `non_constant_identifier_names` to flag local functions.
Change-Id: I830cb452de32ed1b966a176ff88321af9493c62c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/242504
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Right now all type literal usages will perform a runtime call which is
rather slow.
Flutter happens to use type literals such as `return T;` in hot code
which causes this to show up in the profile.
This CL adds fast paths for type parameter type literals if
the type parameter value (i.e. entry of TAV corresponding to T):
* is `null`: return `dynamic`
* is a non-FutureOr [Type] with compatible nullability: return value
* is [FunctionType] with compatible nullability: return value
otherwise fall back to runtime call.
It makes simple type literal uses 10x+ faster - the kinds that Flutter
is using.
Issue https://github.com/dart-lang/sdk/issues/48757
TEST=vm/dart{,_2}/instantiate_type_literal_test
Change-Id: I1139d6689aedbc68321f47ee6c9946a3323fbf6e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241968
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
