Adopt ArgumentParser for the command-line tool #154

natecook1000 · 2020-02-27T23:03:05Z

This adopts the new ArgumentParser library for parsing command-line arguments.

fernandodev · 2020-02-28T14:28:50Z

Package.swift

@@ -23,9 +23,10 @@ let package = Package(
  dependencies: [
    .package(
      url: "https://github.com/apple/swift-syntax",
-      .revision("swift-DEVELOPMENT-SNAPSHOT-2020-01-29-a")
+      .branch("master")


better to use a specific branch, tag or commit

such as swift-5.2-branch

For the swift-syntax dependency, please revert this back to the development snapshot that we were previously using. (We plan to switch to master soon so that we can hook into Swift's CI and have it build using the toolchain sources to detect breakages if someone updates the syntax definitions in an apple/swift PR, but we need to do some other prep work for that first.)

allevato

The new argument parser looks great! Really excited to start using it. A few questions/comments below.

allevato · 2020-02-28T16:50:29Z

Package.swift

@@ -23,9 +23,10 @@ let package = Package(
  dependencies: [
    .package(
      url: "https://github.com/apple/swift-syntax",
-      .revision("swift-DEVELOPMENT-SNAPSHOT-2020-01-29-a")
+      .branch("master")


For the swift-syntax dependency, please revert this back to the development snapshot that we were previously using. (We plan to switch to master soon so that we can hook into Swift's CI and have it build using the toolchain sources to detect breakages if someone updates the syntax definitions in an apple/swift PR, but we need to do some other prep work for that first.)

allevato · 2020-02-28T17:01:32Z

Sources/swift-format/CommandLineOptions.swift

+      throw CleanExit.message("0.0.1")
+    }
+
+    if inPlace && (mode == .format || paths.isEmpty) {


It looks like part of this got flipped; it should be mode != .format.

allevato · 2020-02-28T17:13:56Z

Sources/swift-format/Run.swift

-    diagnosticEngine.diagnose(
-      Diagnostic.Message(.error, "Unable to read source for linting from \(assumingFileURL.path)."))
-    return 1
+    throw FormatError.readSource(path: assumingFileURL.path)


In #144, @dylansturg refactored lintMain and formatMain a bit so that the error messages here were sent through the diagnostic engine (instead of being written directly to stderr)—this unified all possible error messages that the tool might emit after argument parsing. For example, we could add a flag later to replace the diagnostic consumer with one that serializes to JSON instead of printing them to stderr, and file I/O errors would be handled seamlessly.

Changing these to throw errors here would revert that back to having two different kinds of behavior for different kinds of errors. Do we need this change?

I'll definitely revert that — it looked like I was replicating the current usage, but of course coalescing errors to look forward at using other outputs makes tons of sense.

allevato · 2020-02-28T17:25:09Z

Sources/swift-format/main.swift

-      return Int32(
-        formatMain(
+extension SwiftFormatCommand {
+  func run() throws {


Since ArgumentParser has subcommand support, it would make sense to have format, lint, and dump-configuration be subcommands with format as the default subcommand. It looks like that would also improve the command line validation because options could be restricted to just the commands that they apply to. But we also have internal tooling that depends on the current command line interface, so we wouldn't want to do that breaking change here yet.

As a possible follow-up PR, does ArgumentParser's design let us easily create those subcommands and then have the old -m/--mode flag delegate to them as a migration path so that we could have both interfaces implemented simultaneously, and then once we have our other tooling no longer depending on the old interface, we could remove it from swift-format?

We should totally be able to have those parallel interfaces. I have an old version of swift-format migrated to a subcommand interface, so after this is ready to merge I'll update that and open another PR.

dylansturg

I notice that whenever there are diagnostics, there's always an extra line printed to stderr that just has "Error:". Presumably that would normally contain a message from the error that was thrown, which is intentionally empty in this case. Is there a way to have a nonzero exit status and not print that extra "Error"? The diagnostics are being printed, so I don't think there's a need to also print that there was an error.

dylansturg · 2020-02-28T22:36:57Z

Sources/swift-format/Run.swift

@@ -76,7 +75,7 @@ func lintMain(
 func formatMain(
  configuration: Configuration, sourceFile: FileHandle, assumingFilename: String?, inPlace: Bool,
  debugOptions: DebugOptions, diagnosticEngine: DiagnosticEngine
-) -> Int {
+) {
  let formatter = SwiftFormatter(configuration: configuration, diagnosticEngine: diagnosticEngine)


I recently changed this to pass nil, so that DiagnosticEngine is only used for fatal messages when formatting, in #155. It looks like this is causing a merge conflict - can you update and resolve the conflict?

natecook1000 · 2020-02-29T00:43:10Z

@dylansturg:
Is there a way to have a nonzero exit status and not print that extra "Error"?

Good point. This looks like something we'll want to add to ArgumentParser.

allevato · 2020-03-02T16:50:08Z

Good point. This looks like something we'll want to add to ArgumentParser.

Is this something you'd add in the near future or later? If it's soon we could just wait for it, but if it's later, I don't want to block the rest of this change on it. @dylansturg suggested offline that we could change the FormatError message to something like "Exiting due to previous errors." The extra message isn't ideal but at least it would be temporary, and you could tag the message with a TODO comment to replace it once we have a way to silently exit with a non-zero status.

natecook1000 · 2020-03-02T17:27:44Z

I'll add it today, so it will be in the 0.0.2 release. We can just leave out the Error: prefix if there's nothing to show afterward.

natecook1000 · 2020-03-09T22:17:44Z

Updated this to use the new ArgumentParser functionality that allows exiting with a failure code without adding to the stderr output.

allevato

Thanks! Alright, let's get this merged. I'm excited to be able to be able to keep building on top of it.

Adopt ArgumentParser for command-line tool

0067ab6

allevato self-assigned this Feb 27, 2020

fernandodev reviewed Feb 28, 2020

View reviewed changes

allevato requested changes Feb 28, 2020

View reviewed changes

Address PR feedback

73d0726

dylansturg reviewed Feb 28, 2020

View reviewed changes

Pass a nil DiagnosticEngine when formatting to match swiftlang#155

2788496

Merge branch 'master' into argumentparser

7e16beb

mollyIV mentioned this pull request Feb 29, 2020

Adopt ArgumentParser for the command-line tool tuist/tuist#1040

Closed

Don't print an additional error message when exiting

8525dfe

natecook1000 requested a review from allevato March 9, 2020 22:16

allevato approved these changes Mar 10, 2020

View reviewed changes

allevato merged commit 6449476 into swiftlang:master Mar 10, 2020

natecook1000 deleted the argumentparser branch March 10, 2020 17:19

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adopt ArgumentParser for the command-line tool #154

Adopt ArgumentParser for the command-line tool #154

natecook1000 commented Feb 27, 2020

fernandodev Feb 28, 2020

fernandodev Feb 28, 2020

allevato Feb 28, 2020

allevato left a comment

allevato Feb 28, 2020

allevato Feb 28, 2020

allevato Feb 28, 2020

natecook1000 Feb 28, 2020

allevato Feb 28, 2020

natecook1000 Feb 28, 2020

dylansturg left a comment

dylansturg Feb 28, 2020

natecook1000 commented Feb 29, 2020

allevato commented Mar 2, 2020

natecook1000 commented Mar 2, 2020

natecook1000 commented Mar 9, 2020

allevato left a comment

Adopt ArgumentParser for the command-line tool #154

Adopt ArgumentParser for the command-line tool #154

Conversation

natecook1000 commented Feb 27, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

allevato left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dylansturg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

natecook1000 commented Feb 29, 2020

allevato commented Mar 2, 2020

natecook1000 commented Mar 2, 2020

natecook1000 commented Mar 9, 2020

allevato left a comment

Choose a reason for hiding this comment