shutdown immediately after starting up
Running the VM with arguments that cause a quick failure _after_ the
service isolate is started could result in the VM service starting and
attempting to register a signal handler after the VM has started
shutting down. The open port held by the signal handler prevented the
message handler from shutting down, resulting in the main thread being
blocked on a monitor in ServiceIsolate::Shutdown.
Could be reproduced with the following commands:
$ rm out/DebugX64/dartdev.dart.snapshot
$ out/DebugX64/dart --observe hello_world.dart
Change-Id: I70ddff73c98151bd7eff22064a23f897b4d6299f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156923
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
connect to DDS without relying on a redirect.
Some WebSocket implementations (particularly dart:html's) don't follow
redirects and don't provide the user with the message returned by the
server.
This CL adds 'getWebSocketTarget' as an RPC which returns the
URI that should be used by the client to connect directly to the proper
web socket target. In addition, the "implicit-redirect" forwarding has
been removed.
Change-Id: Iaf88c965f6fedfa6f63c28a08860a3c80388797c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156485
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
an internal test on Fuchsia.
Change-Id: I1fc6124b7dbdd07a82d09daf5c870971e0c237de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156720
Commit-Queue: Mehmet Fidanboylu <mehmetf@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Both dlopen and LoadLibrary have caching behavior and only load the
dynamic library once into the DartVM, even with multiple isolates.
Change-Id: If16791baf28706c61acb1ecdae668485b264a373
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156682
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Creating a js object with `Object.create(null)` produces an empty
js object with no prototype. Calling methods attached to these
objects would result in a NPE since we assumed all objects would
have a valid `.__proto__`.
Discovered the error in some benchmark code. Created a new test
with the same patterns.
Change-Id: I1fd38893b0c90315b338c3b6a1b4981be1d64065
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156582
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
The previous version include the closing parenthesis in the link on the
dart doc site so it won't lead to the right place when clicked.
Switch to a markdown link instead of a raw URL to avoid ambiguity and
improve readability of the rendered doc.
Do some minor rephrasing of the rest of the comment to remove noise
words, format according to effective Dart.
Change-Id: I497cfeeeff0885eb34e798c469f95dc46f4a81f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156342
Auto-Submit: Nate Bosch <nbosch@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Commit-Queue: Kevin Moore <kevmoo@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Make sure Future.value constructor is inlined, so 'value == null'
test can be removed. Also, removes the implicit cast to FutureOr<T> on
all code paths and only leave a faster 'value as T' cast in case
value == null.
EmptyFutureTest benchmark in AOT/null safety mode on linux/x64: +11.62%
Change-Id: I56916d3a1f6a60e3fc9c50cd565db71aea6ab975
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155928
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
- Makes Future.wait a recognised function, and asserts its chained
future, _future is allocated at a known index in the context.
- Adds logic to locate, extract the chained future during lazy async
stack unwinding.
- Adds tests for the Future.wait async case.
- Minor consistency nits, comments.
This change is similar to a previous CL, adding Future.timeout support:
https://dart-review.googlesource.com/c/sdk/+/152328
Change-Id: I7439750968595d25d7bbac0068ad64fcc891e176
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155420
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The default behavior is controlled via a private configuration variable
settable by embedders (#_mayUseInsecureSocket). It is, by default,
configured to allow insecure connections. The domain configuration
itself is sent as a JSON encoded string which gets parsed once.
Embedders are expected to set these configurations before they run any
user code.
This is a re-work of https://dart-review.googlesource.com/c/sdk/+/142446
[dart:_http] Allow the embedder to prohibit HTTP traffic.
Change-Id: I4ccbd35da9ce25bf5f81ad4468111018d6af2f03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154180
Commit-Queue: Mehmet Fidanboylu <mehmetf@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Towards #42395
These packages are used by benchmarks and need to be migrated to null
safety before stable.
Change-Id: I0b8a24f40384720343364795c60ddaede8fe0de4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156065
Reviewed-by: Jake Macdonald <jakemac@google.com>
Auto-Submit: Nate Bosch <nbosch@google.com>
Now the call in `dtest()` (directly above) is known to never return
so the type of `obj` can be promoted and there is no cast in the
return statement.
Change-Id: I9096dab87cfba5ea2289530070d0214974379ebc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155068
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Also relands the followup CLs:
"Perform non-covariant checks when dynamically invoking callables."
"Use AreValidArguments so that names are checked as well."
Original description of first CL:
This change only affects compilation when running in non-precompiled
mode with --no-lazy-dispatchers enabled.
Instead of always compiling in non-covariant checks, even for closures
not called dynamically, remove the non-covariant checks from the closure
and instead do the non-covariant checks for dynamic calls during the
NoSuchMethodForCallStub fallback by calling
Function::DoArgumentTypesMatch.
Adds two overloads for Function::DoArgumentTypesMatch, one which takes a
function type argument vector and one which takes neither an
instantiator type argument vector or a function type argument vector.
For the versions that are not explicitly passed a type argument vector,
an appropriate one is constructed using the arguments. If there is not
enough information in the arguments, then we fall back to assuming the
empty type argument vector for the instantiator case and instantiating
to bounds in the function type argument case.
Fixes Function::DoArgumentTypesMatch to handle generic functions and to
check arguments appropriately according to the active null safety mode.
For generic functions, the provided or resulting function type vector
has non-covariant checks performed against the type parameter bounds.
This change uncovered one test that was incorrectly passing in strong
mode, see https://github.com/dart-lang/sdk/issues/42688 for details.
Original description of second CL:
The VM only does this when the callable function does not expect dynamic
invocations. Otherwise, performing the checks would be redundant, as the
function body already contains the appropriate non-covariant checks.
Third CL had no additional description.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try,vm-dartkb-linux-release-x64-try,vm-kernel-reload-linux-release-x64-try, vm-kernel-reload-rollback-linux-debug-x64-try
Bug: https://github.com/dart-lang/sdk/issues/40813
Change-Id: I1a3e9c1865103a8d716e1cad814267caffaaadf2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154688
Reviewed-by: Martin Kustermann <kustermann@google.com>
c5a94db091 unintentionally changed the behavior of loadLibrary on a prefix that was already loaded from completing in a future turn of the message loop to completing in the same turn. Completing in the same turn is a legal behavior for loadLibrary, but consistently completing in a later turn helps to prevent code that works on accident.
Bug: https://github.com/dart-lang/sdk/issues/41974
Change-Id: Ib18d16f6b5517c882248f39b486e58e2635f24a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155101
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Compiled output for sound null safety mode no longer needs to check
non-nullable arguments for null.
They can't be null since we no longer allow mixed opt-in/out libraries
when running with sound null safety.
Cleanup a repeated string in the SDK.
Change-Id: Ib7ae86f04660857957b4a7590bc5a7efd2c3fa04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154848
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Update the signature of _startMainIsolate to match _startIsolate with nullable List<String> args. Currently the flutter embedder passes null as the args, which triggers a null assertion with --null_assertions enabled.
See https://github.com/flutter/engine/blob/master/lib/ui/hooks.dart#L224 : the startMainIsolate function referred to is the
_startMainIsolate loaded from dart:isolate
https://github.com/flutter/flutter/issues/61770
Change-Id: Ida4af1f3cb1326d01e1a8d8c41199f44e3651d7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154833
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Jonah Williams <jonahwilliams@google.com>
(Assignment of libraries to loading units is already done in the kernel generation step.)
After compiling and before serializing, we walk the program and for each Code we assign its Instructions, CodeSourceMap and CompressedStackMap to the loading unit of that Code's defining library. Deduplication may cause Instructions, CodeSourceMaps and CompressedStackMaps to belong to more than one loading unit; in this case the objects are assigned to the root loading unit. Later they can be more precisely assigned to the dominating loading unit.
All objects except some Instructions, CodeSourceMaps and CompressedStackMaps belong to the root loading unit's snapshot. This snapshot is written like an unsplit snapshot, except that when serializing Code, we will write a reference to a stub or null when the Code's Instructions, CodeSourceMap or CompressedStackMap belongs to a non-root loading unit. The snapshots of non-root loading units contain these deferred objects and references to the corresponding Code objects to patch. The types of objects we defer (Instructions, CodeSourceMaps and CompressedStackMaps) usually represent 70+% of the snapshot size.
Bare instructions mode must be disabled when splitting because we cannot have PC-relative calls between loading units. Later we can re-enable this for calls within loading units.
Broken: Compactor probably crashes we can now have an unbounded number of image pages and the compactor assumes a fixed number.
Embedder's guide:
At compile-time, gen_snapshot should be passed --loading_unit_manifest with a path, which will enable splitting and output a mapping from loading unit ids to snapshot output paths.
At runtime, sometime during isolate startup, an embedder should call Dart_SetDeferredLoadHandler, probably near an existing call to Dart_SetLibraryTagHandler. The callback is given a loading unit id, and should eventually call Dart_DeferredLoadComplete[Error].
Bug: https://github.com/dart-lang/sdk/issues/41974
Change-Id: Ib597eb87c8cd634416d5ee1f00629c5550aebb00
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152427
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This reverts commit bc4cb123a8.
Reason for revert: breaks crossword simarm tests https://ci.chromium.org/p/dart/builders/ci.sandbox/vm-kernel-precomp-linux-debug-simarm_x64/2619
Original change's description:
> Reland "[ VM / DartDev ] Launch DartDev in an isolate within a single main Dart process"
>
> This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
>
> By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
>
> VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
> Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
> Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/42092)
>
> This reverts commit 3849b5061c.
>
> Change-Id: I4fd3ba33840771a9f284d733c4a25fac6cde64ca
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154706
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,asiva@google.com
Change-Id: I649d94c668417f2edbfd7039fa5c876e10dc32fe
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154800
Reviewed-by: Alexander Aprelev <aam@google.com>
This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/42092)
This reverts commit 3849b5061c.
Change-Id: I4fd3ba33840771a9f284d733c4a25fac6cde64ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154706
Reviewed-by: Siva Annamalai <asiva@google.com>
This reverts commit 556f0fb5c8 and fixes merge conflict.
Revert "[vm] Perform non-covariant checks when dynamically invoking callables." as a collateral.
This reverts commit 7a6287bb92.
Revert "[vm] Use AreValidArguments so that names are checked as well." as a collateral
This reverts commit 90c683018f.
Change-Id: Iee2c5e91c39d19dca7a1e640c103443c95e6c4f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154705
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
This reverts commit ffe258d2d4.
Reason for revert: Failures on bots
Original change's description:
> [ VM / DartDev ] Launch DartDev in an isolate within a single main Dart process
>
> This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
>
> By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
>
> VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
> Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
> Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/41978)
>
> Change-Id: I1c6b1425831b691ad20284716aa80f817dbaf607
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152588
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: Idb1d24a4524bdc3ccfb199a82710f3c0d9db539a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154702
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/41978)
Change-Id: I1c6b1425831b691ad20284716aa80f817dbaf607
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152588
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This change only affects compilation when running in non-precompiled
mode with --no-lazy-dispatchers enabled.
Instead of always compiling in non-covariant checks, even for closures
not called dynamically, remove the non-covariant checks from the closure
and instead do the non-covariant checks for dynamic calls during the
NoSuchMethodForCallStub fallback by calling
Function::DoArgumentTypesMatch.
Adds two overloads for Function::DoArgumentTypesMatch, one which takes a
function type argument vector and one which takes neither an
instantiator type argument vector or a function type argument vector.
For the versions that are not explicitly passed a type argument vector,
an appropriate one is constructed using the arguments. If there is not
enough information in the arguments, then we fall back to assuming the
empty type argument vector for the instantiator case and instantiating
to bounds in the function type argument case.
Fixes Function::DoArgumentTypesMatch to handle generic functions and to
check arguments appropriately according to the active null safety mode.
For generic functions, the provided or resulting function type vector
has non-covariant checks performed against the type parameter bounds.
This change uncovered one test that was incorrectly passing in strong
mode, see https://github.com/dart-lang/sdk/issues/42688 for details.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-dartkb-linux-release-x64-try
Change-Id: I5030a46b356778448b51a243f16406eacf1c04bf
Bug: https://github.com/dart-lang/sdk/issues/40813
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153202
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This makes both compilers report a compile-time error when importing dart:mirrors.
Change-Id: I23360b87ee31fba36fe7c111cee1987aa2d50638
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154622
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Eliminated several links to content that no longer exists
Change-Id: Icd7bf5796a061882ba384e39d78d5f8ff429696d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154362
Commit-Queue: Kevin Moore <kevmoo@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Auto-Submit: Kevin Moore <kevmoo@google.com>
This reverts commit f8ff12008e.
This CL is a revert of the initial revert and should be landed once
Flutter changes have been merged to handle the changes here.
Change-Id: I300a5efd776bf2a596743971f4e15ad62da77f5a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153368
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Document that `add` must be implemented when using
`ListMixin` or `ListBase` with Null Safety.
Changes ListMixin.insert to not grow the list itself,
but instead rely on `add` to do that.
This means that a user of ListMixin/ListBase
*only* needs to implement `add`
to support growing a list with non-nullable elements
(which they do need to because of Null Safety).
Fixes#42496
Bug: http://dartbug.com/42496
Change-Id: I9476f3111330d7c7f1878f165e066f86d3108b87
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152853
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Now that the sound null safety mode is a compile time flag
instead of a runtime flag there is no need to set the value in
the bootstrapping code before running main(). The sound and weak
versions of the sdk now have it already set.
Add compileTimeFlag() method that will inline the constant value
directly into the generated output.
Change-Id: I5b9243c47cffc421067ac820ef49342b9d0efff9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154100
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Two tricks let us compile this more efficiently:
e.children.addAll(cs);
Normally, get$children is inlined, returning a _ChildrenElementList
wrapper, generating:
new W._ChildrenElementList(e, e.children).addAll$1(0, cs);
The two tricks:
1. Split _ChildElementList.addAll into an 'unwrap' that then calls the
logic in '_addAll'
2. Add information about the properties of e.children that allow it to
be removed.
With these tricks, dart2js can optimize the code to this version that
avoids allocating a wrapper or accessing the 'children' property:
W._ChildrenElementList__addAll(e, cs);
Change-Id: Ifdf533ac4f9790f09f87302e67304b5696097266
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153904
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
The Dartdoc of the class `Function` claimed that any class with a
`call` method is a subtype of `Function`. That rule is highly obsolete,
and this PR removes it.
Change-Id: I56318f6c6d8a19007c2b6259bc7d84532cd44707
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154004
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
List.generate could return both growable and fixed-size lists.
This change specializes invocations of List.generate when value of
'growable' argument is known (constant or omitted), so it becomes
possible to infer actual type returned by the factory.
This becomes more important with null safety as List.generate is used
more often to initialize lists of non-nullable elements.
Migrated NNBD benchmarks in AOT mode on x64:
Sudoku +11%
DartMicroBenchMM.{Min,Max}Lib +11-13%
DartMicroBenchMM.{Min,Max}Code +19-27%
ForInGeneratedLoop +19%
ForEachLoop +85%
ForInLoop +64%
ForLoop +680%
This change also includes test for inferred types of various List
constructors.
Change-Id: I801231b0a70e3aa8fb14ec9fe749f1dd420b1b9c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153388
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
