This is needed for the Flutter Engine to use a prebuilt Dart SDK as in
https://github.com/flutter/engine/pull/26931. When using a prebuilt
Dart SDK, the rules producing the built SDK are directed to a
different location so that GN doesn't warn about multiple rules that
produce the same file.
TEST=locally with a flutter/engine checkout
Change-Id: I4095f379c772c63f93a1c88c7f4e44804f3a6fc7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204760
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
This reverts commit 659fdae898.
Reason for revert: Broke the HHH bots.
The fix according to zra@ should be:
"The new dependencies should be added as dependency overrides to flutter_frontend_server's pubspec.yaml: https://github.com/flutter/engine/blob/master/flutter_frontend_server/pubspec.yaml"
Original change's description:
> Move most of the code from u/b/kernel_worker.dart to p/frontend_server
>
> This should allow us to import the code in cases when we want to
> implement the Bazel worker loop ourselves. This opens some possibilities
> of extra optimizations for internal use cases.
>
> I'm leaving some of the code (e.g., `main`) in the old location, so that
> we do not break anything that depends on it.
>
> The only thing that I've done is to pass the input-digest map to
> `computeKernel` instead of using `Input` objects directly, this way
> we can avoid the dependency on `package:bazel_worker` from
> `frontend_server`. So now, if we're using the worker loop, the map will
> be computed by `kernel_worker.dart` (in non-worker mode, we rely on
> the default empty map).
>
> Bug: http://b/187910394
> Change-Id: I408407ebdebc17c7898552c053a8e1c269cf2df5
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/201187
> Commit-Queue: Michal Terepeta <michalt@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: http://b/187910394
Change-Id: Ieb44d61b668a7d4629a27eef5a6ef61d0db9deaf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/201880
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
This should allow us to import the code in cases when we want to
implement the Bazel worker loop ourselves. This opens some possibilities
of extra optimizations for internal use cases.
I'm leaving some of the code (e.g., `main`) in the old location, so that
we do not break anything that depends on it.
The only thing that I've done is to pass the input-digest map to
`computeKernel` instead of using `Input` objects directly, this way
we can avoid the dependency on `package:bazel_worker` from
`frontend_server`. So now, if we're using the worker loop, the map will
be computed by `kernel_worker.dart` (in non-worker mode, we rely on
the default empty map).
Bug: http://b/187910394
Change-Id: I408407ebdebc17c7898552c053a8e1c269cf2df5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/201187
Commit-Queue: Michal Terepeta <michalt@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
When constructing the command line for creating the kernel service
snapshot, the variable `abs_output` actually contains a relative
path, which means that copy/pasting the generated command line fails
if not within the root build directory. This CL fixes that.
Previous revert: https://dart-review.googlesource.com/c/sdk/+/200940
Passes `--depfile-output-filename` with the path relative to the output
folder so that the written depfiles do not contain the absolute file
paths.
ninja only accepts paths relative to the build folder in the .d files.
Manually tested that the dependencies now work with running the
build twice:
`tools/build.py --no-start-goma -mrelease create_platform_sdk`
Inspecting the .d file in question that caused the revert:
`cat out/ReleaseX64/gen/kernel-service.dart.snapshot.d`
TEST=SDK build
Change-Id: Id781d2ed94ad7a0041e5899b8fded598de81242b
Cq-Include-Trybots: luci.dart.try:dart-sdk-linux-try,dart-sdk-mac-try,dart-sdk-win-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/200876
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
This reverts commit 269828ed34.
Reason for revert: This causes subsequent builds to be dirty no matter what.
Original change's description:
> [build] Use an absolute path for the snapshot.
>
> When constructing the command line for creating the kernel service
> snapshot, the variable `abs_output` actually contains a relative
> path, which means that copy/pasting the generated command line fails
> if not within the root build directory. This CL fixes that.
>
> Change-Id: I0d9fcafac489a6bd4771de1d6db1a2aa3623dcf8
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/200861
> Reviewed-by: Daco Harkes <dacoharkes@google.com>
> Commit-Queue: Tess Strickland <sstrickl@google.com>
TBR=dacoharkes@google.com,sstrickl@google.com
Change-Id: I601d3c878d65ad6294d8f20c8b53d119b251ff43
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/200940
Reviewed-by: Dan Field <dnfield@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
When constructing the command line for creating the kernel service
snapshot, the variable `abs_output` actually contains a relative
path, which means that copy/pasting the generated command line fails
if not within the root build directory. This CL fixes that.
Change-Id: I0d9fcafac489a6bd4771de1d6db1a2aa3623dcf8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/200861
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
* Migrate to python3; drop python support.
* Update Windows toolchain support.
* Remove some unused methods.
* Python 2.7 is still needed on Windows.
* Update gsutil to a version that supports python3.
Fixes: https://github.com/dart-lang/sdk/issues/28793
TEST=Manually tested common user journeys.
Change-Id: I663a22b237a548bb82dc2e601e399e3bc3649211
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/192182
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Since the flag is now enabled by default, there should be no mention of it.
There are still some uses in front_end/testcases that are not just removable
(it also uses `no-non-nullable`). There migth be more uses that are not
as easily found as grepping for `--enable-experiment
Removes two VM tests where fixing them meant they were just duplicating
the corresponding non *_2/ tests.
Fixes#44941
TEST= Large number of tests chaged.=(no-)?non-nullable`.
Change-Id: Ief755981ccde9a5482fcdf408c2929c74433a710
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183688
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
This change tries to run from dartdev.dart.snapshot and falls back to
running from dartdev.dill if incompatible VM flags are provided.
Fixes https://github.com/dart-lang/sdk/issues/43969
Performance results:
dart test.dart (no CLI isolate): 0.167s
dart run test (from snapshot): 0.208s
dart run test (from kernel): 0.326s
TEST=pkg/dartdev/test/load_from_dill_test.dart
Change-Id: I3195886b86676580ef2a0221f0284328964ef061
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178300
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Opt an initial batch of files under samples, samples-dev,
utils, and runtime/tools/dartfuzz out of null safety in preparation
for switching the flag on by default.
Change-Id: Icdfd52a5a969e678a7205903332f73fe3841c223
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166960
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Leaf Petersen <leafp@google.com>
Several people have experienced build issues traced back to
target `//utils/dartanalyzer:generate_summary_strong`.
The issue is triggered by the sdk_hash changing with an old
kernel-service snapshot in the out/ folder.
`generate_summary_strong` uses but does not explicitly depend on
the kernel-service, causing the outdated dependency.
This then causes 'Unexpected Kernel SDK Version' when the new dart
binary tried to load the old kernel-service snapshot.
Tested:
1. Clean build of create_sdk at HEAD.
2. Empty `git commit --amend` to modify commit and thus sdk hash.
3. Rebuild of create_sdk (which failed before).
Cq-Include-Trybots: dart/try:analyzer-analysis-server-linux-try,analyzer-linux-release-try,analyzer-mac-release-try,analyzer-nnbd-linux-release-try,analyzer-win-release-try,benchmark-linux-try,dart-sdk-linux-try,dart-sdk-mac-try,dart-sdk-win-try,dart-sdk-win-try,flutter-analyze-try,front-end-linux-release-x64-try,pkg-linux-release-try,vm-kernel-linux-release-x64-try
Change-Id: Iba07e9d0c5daa7a93870fb501d9bb57682c88a5d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156913
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Clement Skau <cskau@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>
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>
This reverts commit edde575dcd.
Reason for revert: Breaks the Dart to Flutter roll and golem
Original change's description:
> [SDK] Adds an SDK hash to kernels and the VM.
>
> 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.
>
> Bug: https://github.com/dart-lang/sdk/issues/41802
> Change-Id: I3cbb2d481239ee64dafdaa0e4aac36c80281931b
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150343
> Commit-Queue: Clement Skau <cskau@google.com>
> Reviewed-by: Jens Johansen <jensj@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
TBR=kustermann@google.com,jensj@google.com,cskau@google.com
Change-Id: I34cc7d378e2babdaaca4d932d19c19d0f35422fc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: https://github.com/dart-lang/sdk/issues/41802
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152703
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
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.
Bug: https://github.com/dart-lang/sdk/issues/41802
Change-Id: I3cbb2d481239ee64dafdaa0e4aac36c80281931b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150343
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This is the first step to removing all of the the sdks precompiled
to JS modules from the sdk download.
Enables build_runner to produce a JS file on demand from a .dill
file bundled in the sdk download. At this time, only the SDK can
be compiled from a .dill file.
Update build targets to run bin/dartdevc.dart instead of
tool/compile_dartdevc_sdk.dart.
Will delete tool/compile_dartdevc_sdk.dart after we cleanup all
of the uses outside of the SDK.
Change-Id: Id6002675419e8e502912cb3f5b626a0d13461df5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151025
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Zach Anderson