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>
On Windows platform, backslashes are used as path separator. (Forward
slashes are also accepted by Windows APIs for most cases) But for an Uri
backslashes will be percent-encoded in the Uri. The other problem is
that "C:\directory" when passed into Uri, the drive letter will be
misinterpreted into scheme (common schemes like "http" or "file").
Bug: https://github.com/dart-lang/sdk/issues/42874
Change-Id: I0fe287b65a5b4faeb791665d2fda9ea0a9744cc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156363
Commit-Queue: Zichang Guo <zichangguo@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Instead of spawning new processes to run a tool for a command, this
change makes it so we run within the current process when possible. In
general, we should avoid spawning any processes when possible from
dartdev unless:
- We need to interact with the child process from dartdev (e.g.,
analysis server)
- The child needs to interact with the parent process (e.g., DDS)
Change-Id: I9c8cd39de038ab2f3a699165a47bee4c281bda67
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156048
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Ben Konyi <bkonyi@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>
I thought that this landed over a month ago. This needs to be rolled into the Dart SDK 2.9
New output from dart format --help:
Idiomatically formats Dart source code.
Usage: dart format [options...] <files or directories...>
-h, --help Print this usage information.
Common options:
-o, --output Where formatted output should be written.
[json] Print code and selection as JSON
[none] Discard.
[show] Print code to terminal.
[write] (default) Overwrite formatted files on disc.
--show Which filenames to print.
[all] All visited files and directories.
[changed] (default) Only the names of files whose formatting is changed.
[none] No file names or directories.
--summary Summary shown after formatting completes.
[line] (default) Single line summary.
[none] No summary.
[profile] Tracks how long it took for format each file.
Non-whitespace fixes (off by default):
--fix Apply all style fixes.
--fix-doc-comments Use triple slash for documentation comments.
--fix-function-typedefs Use new syntax for function type typedefs.
--fix-named-default-separator Use "=" as the separator before named parameter default values.
--fix-optional-const Remove "const" keyword inside constant context.
--fix-optional-new Remove "new" keyword.
--fix-single-cascade-statements Remove unnecessary single cascades from expression statements.
Other options:
-l, --line-length Wrap lines longer than this.
(defaults to "80")
-i, --indent Spaces of leading indentation.
(defaults to "0")
--set-exit-if-changed Return exit code 1 if there are any formatting changes.
--follow-links Follow links to files and directories.
If unset, links will be ignored.
--version Show version information.
Options when formatting from stdin:
--selection Selection to preserve formatted as "start:length".
--stdin-name The path name to show when an error occurs.
(defaults to "stdin")
Run "dart help" to see global options.
Change-Id: I18a49abd919672e988296f83c23636b14c29bdeb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153900
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Jaime Wren <jwren@google.com>
If a user program installs custom signal handling for SIGINT,
the DartDev instance may exit before its child, potentially causing
confusing behavior and 'zombie' children. By ignoring these signals in
DartDev, the DartDev instance will only exit once its child process
exits.
Fixes https://github.com/dart-lang/sdk/issues/42092
Change-Id: I04bf6d1f375b8bb3a4f7022f2c79ddde3bd5f414
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149643
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Jaime Wren <jwren@google.com>
Supports compiling to snapshots, JS, native executables, and kernel:
$ dart help compile
Compile Dart to various formats
Usage: dart compile <subcommand> [arguments]
-h, --help Print this usage information.
Available subcommands:
aot Compile Dart to an AOT snapshot
exe Compile Dart to a self-contained executable
jit Compile Dart to a JIT snapshot
js Compile Dart to JavaScript
kernel Compile Dart to Kernel intermediate format
Change-Id: I1143f8dd0eec6f87a8271144f92dedc1fcf82923
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/146806
Commit-Queue: Michael Thomsen <mit@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Jaime Wren <jwren@google.com>
From the original upload, this change has been updated to include:
- a new flag to disable analytics when running dartdev tests
- some tests on the analytics.dart utility methods
- logic for recording flags and options on dartdev cli calls
- message printed when the user runs the sub command `dart disable-analytics`
- a valid tracking ID
Change-Id: Ifeb4d0669b9fc53b62fea88285e5ac78cc8e14a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147823
Commit-Queue: Jaime Wren <jwren@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
```
$ flutter help create
Create a new Flutter project.
Usage: flutter create <output directory>
-h, --help Print this usage information.
-t, --template=<type> Specify the type of project to create.
```
Change-Id: I3933eabc758988950cb34cea6982eb342a391823
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148130
Reviewed-by: Jaime Wren <jwren@google.com>
Commit-Queue: Michael Thomsen <mit@google.com>
This flag was needed back when we had a forked SDK, to handle the fact
that the migration tool had different expected behaviors depending on
whether it was run against a pre-NNBD or a post-NNBD SDK. Now that
the post-NNBD SDK has landed, we don't need it anymore.
Change-Id: Ia420fbf0d266a32e4c3030a2b8d0e712ee12eecf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148514
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
We no longer use the analysis server or dartfix for migration.
This should unblock removing migration integration from dartfix, which
will unblock publishing dartfix.
It should also pave the way for future changes that will allow us to
publish the NNBD migration tool on pub, which in turn will allow us to
provide updates and bug fixes to the migration tool without having to
publish a new Dart or Flutter SDK.
Change-Id: I9f128b61a2983befc5ef686867dab3db87fd6855
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148020
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is a reland of 604a366065
Original change's description:
> [ VM / DartDev ] Run all debugging sessions via 'dart run'
>
> Prior to this change, running `dart --observe foo.dart` would result in
> the DartDev flow being bypassed. While `dart foo.dart` will continue to
> bypass DartDev and be run directly, running either `dart --observe
> <vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
> will result in the command being implicitly converted to `dart run
> --observe <vm-flags> foo.dart`. This is required for all standalone VM
> instances to run against DDS instead of the VM service directly.
>
> As usual, the DartDev flow can always be bypassed by providing the
> --disable-dart-dev flag.
>
> Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
Change-Id: I917d3056322d74766bdf376a3e28871ad5b66cfa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147980
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This reverts commit 604a366065.
Reason for revert: Breaks google3, see b/156414355
Original change's description:
> [ VM / DartDev ] Run all debugging sessions via 'dart run'
>
> Prior to this change, running `dart --observe foo.dart` would result in
> the DartDev flow being bypassed. While `dart foo.dart` will continue to
> bypass DartDev and be run directly, running either `dart --observe
> <vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
> will result in the command being implicitly converted to `dart run
> --observe <vm-flags> foo.dart`. This is required for all standalone VM
> instances to run against DDS instead of the VM service directly.
>
> As usual, the DartDev flow can always be bypassed by providing the
> --disable-dart-dev flag.
>
> Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: I688a3779e7ccaf85a28dc4d6f5ccf23596109519
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147900
Reviewed-by: David Morgan <davidmorgan@google.com>
Commit-Queue: David Morgan <davidmorgan@google.com>
Prior to this change, running `dart --observe foo.dart` would result in
the DartDev flow being bypassed. While `dart foo.dart` will continue to
bypass DartDev and be run directly, running either `dart --observe
<vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
will result in the command being implicitly converted to `dart run
--observe <vm-flags> foo.dart`. This is required for all standalone VM
instances to run against DDS instead of the VM service directly.
As usual, the DartDev flow can always be bypassed by providing the
--disable-dart-dev flag.
Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
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>
Zichang Guo