Some package configuration tests have the current version hardcoded
in local package_config.json files. Update these from 2.9 to 2.10.
Change-Id: I77bf63c0e5dfa73aa8a86fb1b4e8a404e8cfaa7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155441
Reviewed-by: Martin Kustermann <kustermann@google.com>
Previously, we considered an expression unreachable if its type was
exactly `Never`. This CL switches to using TypeSystem.isBottom, which
correctly handles types like `T extends Never`.
Change-Id: Ia6ce580caab6bc7ce7cceb1d0097b50f1da88f8a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154746
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@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>
In weak mode using null in a bool condition results in AssertionError.
In strong mode it results in TypeError (as it is casted to non-nullable
bool).
Test language/vm/bool_check_stack_traces_test is adjusted to account for
both behaviors.
Change-Id: I9c08cf917fb2782dbc6316c5a11cf69003622452
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155041
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
A spread element in a collection literal, e.g., `[...e]` or `{...?e}`,
can have an `e` of type `Null` or a subtype thereof. This CL adds a test
where this situation is created for different types (`Null`, `Never`,
`X extends Null`) with different collection literals, and with and
without elements of other types. In general, the spread does not
contribute any elements, and hence the element/key/value type is `Never`
such that it has no effect on the element/key/value type of the
collection.
Cf. https://github.com/dart-lang/language/pull/1079.
Change-Id: Ib760bcba18045b1afaa50f65c0e7d0a7fe9a8ab6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154693
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Strong mode requires package_config.json to opt-in packages, so
.dart_tool/package_config.json was added for tests which used .packages
file before.
Certain tests for handling custom foo.packages file were marked
to run only in weak mode (as package_config.json would supersede
custom .packages files).
Finally, certain tests were converted to multi-tests with expected
compile-time errors to reduce number of failing tests (compile-time
error was an expected behavior for those tests, just not reflected
in the test sources).
Change-Id: Id5a3140ee033c115221b2f4a0b12adf40b6de415
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154831
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This test exercises recursive static field initialization.
Under the new language semantics all static fields are implicitly late,
The test was using 'final' fields, which can be initialized only once,
but the test attempted to initialize those fields multiple times
during recursive invocation. This results in LateInitializationError.
So the test is updated to use non-final fields which allow
multiple writes.
Relevant paragraph from the spec:
Let D be a late and final local variable declaration named v. It is a run-time error, throwing an instance of LateInitializationError, to assign a value to v if a value has previously been assigned to v.
Note that this includes the implicit initializing writes induced by evaluating the initializer during a read.
Change-Id: I577cb9d189c1e6975ea5f21fab64d5b1204315d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154823
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Alexander Markov <alexmarkov@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 test looks like it is intended for the analyzer/CFE only.
Since it is a multi-test there are hundreds of tests being run on
all backends with the exact same results on every CI and CQ run.
The structure and the nature of cascading errors from some of the
keywords means this test isn't easily adaptable to a static error
test.
Change-Id: Ida842051982cbb0a59caec45b28bca993d0edc2a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154751
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Nicholas Shahan <nshahan@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>
The fixes to list_concurrent_modify_test are I think correct and
preserve the intent of the test. The changes to list_test get the test
working correctly and preserve the intent of the test but are
workarounds that shouldn't be needed once #42496 is fixed.
Change-Id: I82b32b2256b9940ceb934fb0f628311b8e7c6567
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152988
Commit-Queue: Leaf Petersen <leafp@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
The bootstrapping was still loading the wrong version of the sdk and
pre-compiled packages when running tests for DDC.
Update constant_null_safety_mode_test to test a constant that is
defined within the sdk itself in addition to one defined in the test.
Change-Id: I8938ed92d866cfca0ce42567f03bed5f3dd9f10c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154121
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
The focus event stream is typed to be non-nullable. Updated the
return of the function passed to reduce in the "_2" version as
well to keep them consistent.
Change-Id: Ic1ae2e027c184d751549c989d60924360139fd5c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154140
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Adds tests for type checks and casts using JS classes and object
literals. Checks typing between different classes, same classes,
object literals, subtypes, and dynamic conversions.
Change-Id: I01c384395f0e6c8d671ac9bd0dc6e6905845a760
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152990
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
There are several scenarios in which the flow analysis implementation
needs to be careful to mark variables as "not definitely unassigned",
even though they are not definitely assigned. These scenarios are
handled by the implementation but not yet properly spec'ed. Prior to
updating the spec, I wanted to make sure we had adequate test cases.
Change-Id: Id3f82279e0686f9cccfabd834396f05b8b28bcab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153825
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
+ use the inferred return type in error reporting when no return type is
declared. This turned up in this particular case where we report an
error between the returned value and the inferred return type.
Closes#42546
Change-Id: I48da24047f2e92ca91a514dfcb43c2ba6f65ee46
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153610
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
William Hesse