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>
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 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>
There is no functional change to the analyzer or CFE yet; we simply
report the error in the parser listeners now rather than the parser
itself. In follow up CLs when we add full support for the feature, we
will want to keep the error reporting logic, but only report the
errors in pre-NNBD code.
Change-Id: Ifd14dd97d7d1d57586a8e14a25103356d54f0ea1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154364
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The future non-basic version is to include the following:
* adding missing annotations on nodes
* adding URIs and file offsets to the nodes
* adding nullability markers to types
* stylistic changes
* optimizations
* better surface syntax
* better error messages
Change-Id: If2fc51e4932d9043dd1719b766bd23ff4e0fc1ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154001
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
This CL adds round-trip serialization support for FunctionDeclarations
and the remining kinds of VariableDeclarations, completing the support
for statements. Additionally, the CL fixes a variable scope issue in
Catch clauses, namely that the exception and the stack trace variables
should be visible in the body.
Change-Id: I3843d491b85a65c4953d6fc10a59ecbde5017029
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153611
Reviewed-by: Johnni Winther <johnniwinther@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>
Before this CL, if one compiled a script as strong nnbd (with nnbd
enabled), where the script was marked as as a version where nnbd is enabled,
but where the script lived in a package with a version that was too low
one would get an error.
The reason is that the language version is set twice:
First when the library is created (but the file isn't read yet). This sets
the version from the package. Here an error was issued.
The second time is when the file is read and the file-version-marker is
parsed (e.g. @dart = 2.9).
The error should only be given if - once the final verison has been set
(i.e. after parsing the file) - the version is "wrong".
To make matters worse the (bogus) error given even points to the files
first position which can make it seem like it specificly points to the
@dart annotation and says it's wrong.
This CL fixes the error so it's only issued when it should be.
It does not fix pointing semi-weirdly.
Fixes https://github.com/dart-lang/sdk/issues/42323
Bug: 42323
Change-Id: Id84ca06b2e4eca5912e65798ed2d86f8c89d71a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153769
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@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>
Note: This is a reland of https://dart-review.googlesource.com/c/sdk/+/150343
Adds a new SDK hash to kernels and the VM which is optionally checked
to verify kernels are built for the same SDK as the VM.
This helps catch incompatibilities that are currently causing
subtle bugs and (not so subtle) crashes.
The SDK hash is encoded in kernels as a new field in components.
The hash is derived from the 10 byte git short hash.
This new check can be disabled via:
tools/gn.py ... --no-verify-sdk-hash
This CL bumps the min. (and max.) supported kernel format version,
making the VM backwards incompatible from this point back.
This also bumps the min. and current ABI version.
Bug: https://github.com/dart-lang/sdk/issues/41802
Change-Id: I2f85945045a603eb9dcfd1f2c0d0d024bd84a956
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152802
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Previously the first file in the `Component.uriToSource` was used which
didn't work nicely with multifile tests.
Text outline expectations were already using the test description uri.
Change-Id: I0d4a7493cd1fa61beffba41f1ea859ca5e8ad08c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151825
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
If 'growable' argument of List.filled factory invocation is known at
compile time we can replace it with more specialized constructors
creating growable or fixed-size lists. This results in a more accurate
inferred type and more efficient code which uses the created list.
Fixes https://github.com/dart-lang/sdk/issues/42551
Change-Id: I427e1bdb8a0f2a83410a9533050d19cbca2d27d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153064
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
William Hesse