Avoid sharing manifests between components, which confuses `fuchsia_component`.
Change-Id: I2a035e6257284a9e8ff5da18f7c2e212e0a9091f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/282120
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This should make vm/dart_2/analyze_snapshot_binary_test pass on
dartkp-linux-release-arm64 & dartk-linux-release-arm64
by ensuring arm64 `gen_snapshot` & `analyze_snapshot` binaries
are available on the device when running tests on arm64 HW.
Change-Id: Icd814ff6df22a33b651733e4c3dc99873cf56a58
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279970
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Updated strictness on build configuration for analyze_snapshot
Will run only under Linux/Android 64 bit arm, arm64c, simarm64,
simarm64c and x64 architectures.
analyze_snapshot just has a single target that links into product precompiled programatically
Testing suite updated to comply with null-safety requirements and
fix for simulated platform failing to use gen_snapshot with assembly.
TEST=ci
Change-Id: I3d58400db2e26a441a40fe7197b22510a52732b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279391
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Chris Evans <cmevans@google.com>
We use binaryen from googlesource mirror with commits that have already
been rolled into g3.
Since binaryen doesn't come with GN files (it uses cmake), we add
our own in third_party/binaryen/BUILD.gn.
TEST=ci
Change-Id: Iee5c37c9d391ee41dc57250d7a33177cbe9ed2aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/270640
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
The `dartaotruntime` is built in `product` mode even when we do a release build. This CL wires up a product flag so we always build the Dart2Wasm product snapshot when creating the SDK.
Change-Id: Ic8c6a6da180a47a19ba818d7c449f712c9e60123
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/264887
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Change-Id: Iea75c14b6709f2347fe82af2ef226a1ed068d8a6
Cq-Include-Trybots: luci.dart.try:dart-sdk-linux-try,dart-sdk-mac-arm64-try,dart-sdk-mac-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261502
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This CL introduces a new kernel-to-kernel pass in Wasm backend to
compile `FfiNative`-annotated external functions to external functions
with `wasm:import` pragmas.
The new pass `WasmFfiNativeTransformer` extends `FfiNativeTransformer`.
Some `FfiNativeTransformer` methods made public to allow reuse in the
pass.
The conversion works like this: when we see a member like:
@FfiNative<Int8 Function(Int8, Int8)>("ffi.addInt8")
external int addInt8(int a, int b);
We generate a Wasm import using Wasm ABI types according to emscripten
calling conventions:
@pragma('wasm:import', 'ffi.addInt8')
external static WasmI32 addInt8_$import(WasmI32 a, WasmI32 b);
and convert the original member (`addInt8()`) to a wrapper function that
calls the Wasm import, converting the arguments and return values to
Dart types:
static int addInt8(int a, int b) {
return WasmI32.toIntSigned(
addInt8_$import(
WasmI32::int8FromInt(a),
WasmI32::int8FromInt(b),
));
}
Build, test, and CI changes:
- Test runner now uses `// SharedObjects=...` lines in dart2wasm tests
to pass extra Wasm modules to d8 command used to run the tests.
Support for `// SharedObjects=...` lines were already used in
native/AOT FFI tests, not added in this CL. We just start to use those
lines in dart2wasm tests.
- dart2wasm gn file updated with a target "test_wasm_modules" that
builds FFI test Wasm modules to Wasm using emcc (emscripten C
compiler).
- CI dart2wasm_hostasserts configuration updated to copy the Wasm files
generated by the "test_wasm_modules" target to the shards.
TEST=tests/web/wasm/ffi_native_test
Change-Id: I6527fe4e2ca2b582e16d84fee244e9cbe6dee307
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252822
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This adds a --platform= option to dart2wasm to read the SDK libraries
from that dill file instead of compiling them from source every time.
If the option is not given, the SDK libraries are compiled, like before.
Also adds a "dart2wasm" build target, which will build the dart2wasm
platform dill and compile dart2wasm to two AOT snapshots (with and
without asserts). The dart2wasm scripts in sdk/bin are updated to run
via these snapshots and use this platform dill.
This speeds up test runs for the dart2wasm-hostasserts-linux-x64-d8
configuration by approximately 45x.
Change-Id: If2c7750a6eb39725310745f887792784d0dfc583
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243624
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
This is a reland of 19e5749308
TEST=runtime/tests/vm/dart/analyze_snapshot_binary_test.dart
Original change's description:
> [vm] Add analyze_snapshot tool for AOT snapshot inspection
>
> Current skeleton to allow for instrumentation snapshots that can be
> built alongside Dart compilation artifacts and easily referenced for
> specific versions between Snapshot hash <-> DartSDK <-> Flutter Engine
>
> TEST=runtime/tests/vm/dart/analyze_snapshot_binary_test.dart
>
> Change-Id: Ie3757a265bbf457506c72fb62a625fea7bedcb68
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/221087
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Commit-Queue: Slava Egorov <vegorov@google.com>
Change-Id: Ia1ea0071d30818440ae48484ff6c406236af5a4e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/224526
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Current skeleton to allow for instrumentation snapshots that can be
built alongside Dart compilation artifacts and easily referenced for
specific versions between Snapshot hash <-> DartSDK <-> Flutter Engine
TEST=runtime/tests/vm/dart/analyze_snapshot_binary_test.dart
Change-Id: Ie3757a265bbf457506c72fb62a625fea7bedcb68
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/221087
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Per breaking change #45451 we are removing support for dart-ext:
style native extensions from the Dart VM.
This CL removes the associated VM code, tests and samples. It also ports
a single test which used dart-ext: import to use FFI instead.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/45451
Change-Id: Iae984bce32baf29a950b5de1323939006a217b94
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212050
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Remove the runtime_kernel target and all uses of it in scripts or
the test matrix. This runtime_kernel target is only an alias for
the runtime target, now that kernel is the default.
BUG=https://github.com/dart-lang/sdk/issues/46892
Change-Id: I00c0ecf8adbd7bff3fd3df48023a2976c5172066
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210000
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: William Hesse <whesse@google.com>
The code has been dead for quite some time.
TEST=ci
Change-Id: Iddcb63e14e9e4d95230f006ac05da64f444f0712
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190024
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This does not include enabling the FFI on Fuchsia. So these tests will
fail without the dependent CL.
This CL adds an `all_positive.dart` test file to be packaged in the
.far file, such that it is easier to run all FFI tests in one go.
We don't run tests on the bots, but we do build this test package on
the bots.
To build the .far files locally:
```
tools/build.py --os=fuchsia -m debug fuchsia_ffi_test_package
tools/build.py --os=fuchsia -m debug -a arm64 fuchsia_ffi_test_package
```
Issue: https://github.com/dart-lang/sdk/issues/44434
Change-Id: Iec418e0c10d77afbf811fb83151664bcc2710b99
Cq-Include-Trybots: luci.dart.try:vm-fuchsia-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175484
Reviewed-by: Liam Appelbe <liama@google.com>
This CL introduces unit tests for the Native* classes in compiler/ffi
that can run for all supported target ABIs on any host architecture.
The unit tests are compiled for all target ABIs with
`tools/build.py run_ffi_unit_tests` and run for all target ABIs with
`tools/test.py ffi_unit`.
The unit test and tested code do not conceptually depend on having a
DartVM. The tests are compiled with a custom `dart::Zone` and
`platform/`. This enables compiling for all `TARGET_ARCH_*` and
`TARGET_OS_*` on any host, and running unit tests for all target ABIs
on any host.
Because the `run_ffi_unit_tests` executables do not include the DartVM
their build is quick (<10seconds) and they are small (~6MB) when
compared to `run_vm_tests` (~250MB).
The tests are added to the existing FFI QEMU bot to prevent adding an
extra bot which would add checkout overhead.
The unit tests themselves are set up to be fairly similar to vm/cc
tests. The only difference is the NativeCallingConvention tests which
are set up with `.expect` files for easy inspection and updating.
TEST=runtime/vm/compiler/ffi/native_calling_convention_test.cc
TEST=runtime/vm/compiler/ffi/native_location_test.cc
TEST=runtime/vm/compiler/ffi/native_type_test.cc
Change-Id: I7b8bf4de9ef070e7546472217e571a60362b9639
Cq-Include-Trybots: luci.dart.try:vm-precomp-ffi-qemu-linux-release-arm-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/171725
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Clement Skau <cskau@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This reverts commit 17faf89d02.
The fix is in eventhandler_fuchsia.cc. Rather than changing the
condition on line 401, I've just weakened the assert.
Change-Id: Ia6b1f35e479e4b2fdf1adc77e9513551221a7696
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157564
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
The IO tests aren't working yet, but basic tests work:
tools/test.py -n dartk-fuchsia-debug-x64 language_2/list/literal3_test
You may need to run this first:
sudo chmod 666 /dev/kvm
Change-Id: I04915ce11f671f1d493f9eeb6bc832089ba9bfa4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154828
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: William Hesse <whesse@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>
Also, delete some unnecessary files from build/fuchsia, and add an async
dispatcher to os_fuchsia.
Change-Id: I477e58d54330e83b2c7b6463395a1212707f8ab7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154162
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
Everything in the build/fuchsia director (except for tests.cmx) was
copied and modified from:
https://fuchsia.googlesource.com/samples/+/refs/heads/master/build
This doesn't include any tests yet, but its runnable on the emulator.
Change-Id: Id64ae71062447c789ca4d10ed3a4a09e0a6d7b99
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152589
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
Move the nnbd core libraries from sdk_nnbd to sdk, and updates
references in build files and elsewhere accordingly.
Change-Id: I09760fe1e006657aacdfe80f3b22fdf6f7e30a9f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151121
Commit-Queue: Leaf Petersen <leafp@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
- DartDev will now be rebuilt when changes in DDS are made
- Building the `create_platform_sdk` target will build all non-web
components of the Dart SDK, allowing for shorter build times when not
developing web tooling.
Change-Id: I605df4893e93010ba0c0bab0593fb840f1859c07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147807
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
- Flips the flag from --nnbd to --no-nnbd so that by default it builds
the NNBD version
- using the --no-nnbd flag results in the SDK being built in a
directory which has the 'Legacy' suffix added to it
(e.g: out/DebugX64Legacy)
- the '--enable-experiment=non-nullable' flag still needs to be passed
in during execution so that CFE runs in that mode. This is different
from the 'null_safety' flag
Change-Id: I729630a7bd36ea7ae38134f9285b44e93c283c68
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/138902
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
This reverts commit ffbd84d383.
Reason for revert: Failing build on golem and failing test on simarm bot. Will investigate tomorrow.
Original change's description:
> [ dartdev / DDS ] Spawn a Dart Development Service instance when running with --observe via dartdev
>
> Dartdev will now spawn a DDS instance when the --observe flag is
> provided. The stdio streams from the target process are filtered to
> replace any references to the true VM service URI with the DDS URI.
>
> If arguments are provided to --observe to configure the server, the
> arguments will be used when spawning DDS instead of the VM service.
>
> Change-Id: I48888c391135fc9f1e7f92d2a86855071e6b4aaf
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/145680
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
> Commit-Queue: Ben Konyi <bkonyi@google.com>
TBR=jwren@google.com,bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: I750325b45692ff7a40066b37924b01fa98a692d3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/146522
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Dartdev will now spawn a DDS instance when the --observe flag is
provided. The stdio streams from the target process are filtered to
replace any references to the true VM service URI with the DDS URI.
If arguments are provided to --observe to configure the server, the
arguments will be used when spawning DDS instead of the VM service.
Change-Id: I48888c391135fc9f1e7f92d2a86855071e6b4aaf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/145680
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This reverts commit cab69e7706.
Reason for revert: It was a temporary submit
Original change's description:
> [BUILD] - Initial CL to unfork the NNBD Dart SDK
> NOTE: This is a trial submit and will be reverted immediately.
>
> - Flips the flag from --nnbd to --no-nnbd so that by default it builds
> the NNBD version
> - using the --no-nnbd flag results in the SDK being built in a
> directory which has the 'Legacy' suffix added to it
> (e.g: out/DebugX64Legacy)
> - the '--enable-experiment=non-nullable' flag still needs to be passed
> in during execution so that CFE runs in that mode. This is different
> from the 'null_safety' flag
>
> Change-Id: I7d25d9710818af5919c0bb83abe51153172f5886
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144880
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=asiva@google.com
Change-Id: Ib0f99fc1a42c9c7a8b21f8542f4a35dba9105d5c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144900
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
NOTE: This is a trial submit and will be reverted immediately.
- Flips the flag from --nnbd to --no-nnbd so that by default it builds
the NNBD version
- using the --no-nnbd flag results in the SDK being built in a
directory which has the 'Legacy' suffix added to it
(e.g: out/DebugX64Legacy)
- the '--enable-experiment=non-nullable' flag still needs to be passed
in during execution so that CFE runs in that mode. This is different
from the 'null_safety' flag
Change-Id: I7d25d9710818af5919c0bb83abe51153172f5886
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144880
Reviewed-by: Siva Annamalai <asiva@google.com>
