This includes the following pub commits:
git log --format="%C(auto) %h %s" 5b4df5a6f931c63622ac349602d6ef0367e8070f..fb72c1f774ca27556225b207185c0b6b6ab1c274
fb72c1f7 Make `run` available (but deprecated) in the embedding (#2698)
63b56ea4 Return the exit-code from commands (#2689)
7fc4e273 Deprecate top level (#2694)
Change-Id: I5842b1ecb15fc7844d628e2ad5fb00e3f627dbff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168347
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Jonas Jensen <jonasfj@google.com>
Instead of running `pub outdated` to see if the user's dependencies
have been migrated yet, the migration tool now examines all of the
transitive import dependencies of the user's code to see if they are
opted in to null safety. This produces a more accurate result than
`pub outdated`, because it is able to ignore files in transitive
package dependencies that aren't reachable via imports
(e.g. references to `package:analyzer` brought in by `package:test`).
Fixes#44061.
Bug: https://github.com/dart-lang/sdk/issues/44061
Change-Id: I38465bcbf35e8552f0060b5d51c0f1cfc5d18c7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170561
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
where --enable experiment is accepted
Adds --enable-experiment support for:
- dart compile aot-snapshot
- dart compile jit-snapshot
- dart compile js
- dart compile exe
- dart compile kernel
Also changes --enable-experiment from a top level CLI flag to a
per-command flag. --enable-experiment flags will now only be
interpreted by the VM if:
1) They are provided before a CLI command (e.g., dart
--enable-experiment=non-nullable analyze) or
2) They are provided with an explicit or implicit run command (e.g.,
dart --enable-experiment=non-nullable foo.dart or dart
--enable-experiment=non-nullable run foo.dart or dart run
--enable-experiment=non-nullable foo.dart)
This should make it more generally clear where --enable-experiment is
accepted and what subcommands can accept the flag. Prior to this change,
providing --enable-experiment anywhere, even for commands without
experiment support, would not raise an error.
Fixes https://github.com/dart-lang/sdk/issues/43623
Change-Id: I5ec48b2dd2bb6db5526185dae2edbca95ef24d9f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169902
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Jonas Jensen <jonasfj@google.com>
The VM and dartdev were not forwarding --disable-service-auth-codes to
the DDS instance, resulting in auth codes always being enabled.
Change-Id: Ib23bfeb7c64a51fb1229f049a4b61cb1ce5018de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/163261
Reviewed-by: Siva Annamalai <asiva@google.com>
The main reason is that this adds better help text when run from
`dart format`. But it includes a couple of other changes and fixes:
* Don't crash when non-ASCII whitespace is trimmed.
* Split all conditional expressions (`?:`) when they are nested.
* Handle `external` and `abstract` fields and variables.
Change-Id: I59326e693bfe538013cd23b58924461f60e8e908
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160981
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
was overwritten by isolate initialization code
Fixes situation where the following command would fail due to the
dartdev kernel not being compiled with null-safety:
dart --strong-null-safety --enable-experiment=non-nullable run foo.dart
Change-Id: I7e7c980eb3274a51e64c031e6bfef8650b897b8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158345
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Moves the file check after the stderr and exitCode check to show any
process error before checking for success output from the process.
In effect we'll now see the error message from the compiler when the
binary isn't created.
Change-Id: I2fb5c87caf6b87f5cff5c89eccaebd2690b20408
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158009
Auto-Submit: Clement Skau <cskau@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Previously the help messages for 'dart run' were output by a secondary
VM spawned solely to print the VM's help message. However, this help
message was not consistent with those found for other DartDev commands.
With this change, the 'run' command:
- Uses package:args to create a help message consistent with other
DartDev commands.
- No longer accepts arbitrary options and is instead restricted to a
subset of common flags. Passing a VM flag which is not included in
this subset of commands will result in an argument error if passed
*after* the 'run' command. Other VM flags can be passed immediately
following 'dart' and before the DartDev command.
- No longer outputs the VM verbose options when invoked with '--help
--verbose'. VM verbose options and the original VM help message can
be viewed by running 'dart --help --verbose'. This makes uncommon
VM flags used for development less visible to regular users.
- Now properly forwards the subset of VM options accepted by 'run' to
the VM (e.g., 'dart run --observe --no-pause-isolates-on-exit foo.dart'
would have ignored '--no-pause-isolates-on-exit').
Change-Id: Ie56b767cc21e6af3630c742458a6c3e9f7418250
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155841
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
(Disabled; comment in to enable.)
The command calls out to the DAS using the bulk fix protocol to fix all bulk-fixable issues.
Fixable diagnostics are captured in the `BulkFixProcessor.lintProducerMap`.
Sample output:
```
[~/src/repos/dart/sdk/pkg/dartdev] (fix_cmd) $ dart bin/dartdev.dart fix
*** The `fix` command is provisional and subject to change or removal in future releases. ***
Computing fixes in dartdev... 5.0s
Applying fixes to:
lib/dummy2.dart
lib/dummy.dart
Done.
```
Change-Id: I71f82623a452cb747bfc13dba0bb764ec9b1a15b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156046
Reviewed-by: Jaime Wren <jwren@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
This was causing flaky failures when initializing DDS as it was invoking
the getVM RPC which in turn sometimes accessed the script_uri after it
had been freed.
Change-Id: I4454b6fa2da3ad6767938ed12b1013223a667af7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155740
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@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>
Sigurd Meldgaard