Move tools to tool folder.

pkg/front_end/lib/compiler_options.dart

Index: pkg/front_end/lib/compiler_options.dart
diff --git a/pkg/front_end/lib/compiler_options.dart b/pkg/front_end/lib/compiler_options.dart
index 298b45659f72d4c0bafa384225d4dacc1a916f9a..04f516eb3237ed06ef3891e3232b995b4a2815d9 100644
--- a/pkg/front_end/lib/compiler_options.dart
+++ b/pkg/front_end/lib/compiler_options.dart
@@ -217,8 +217,7 @@ class CompilerOptions {
 
   /// Whether the compiler should throw as soon as it encounters a
   /// compilation error.
-  // TODO(sigmund): change the default (issue #30194).
-  bool throwOnErrors = true;
+  bool throwOnErrors = false;

[ahe, 2017/08/23 15:07:18]

This causes all tools to exit with an unhandled exception if a
deprecated_inputError is raised.

The reason is that all fasta subtools are written this way:

    try {
      ...
    } on deprecated_InputError catch (e) {
      exitCode = 1;
      CompilerContext.runWithDefaultOptions(
          (c) => c.report(deprecated_InputError.toMessage(e), Severity.error));
      return null;
    }
  }

And c.report will eventually end up calling _printAndThrowIfDebugging (nee
_printAndThrowIfFatal).

So if you run "pkg/front_end/tool/fasta compile" without arguments, it prints a
usage message and then exits with an uncaught exception (compiler aborted due to
fatal errors).

[Siggi Cherem (dart-lang), 2017/08/23 20:17:34]

I commented on  issue #30194, I think we should instead keep this default as
true for now until we have implemented a full alternative for the public APIs.
Instead, I recommend we change the tools to provide a false value to this
option. One idea to make that kind of change simpler could be to add another
kind of static method in CompilerContext or CompilerCommandLine that defines the
default set of options for command-line tools. For instance:

try {
} on deprecated_InputError catch (e) {
  ...
  CompilerContext.runWithCommandLineOptions((c) => ...);
}

[ahe, 2017/08/24 11:52:01]

I'd rather go ahead with this and let the resolution of issue 30194 deal with
the default behavior in the public API. I don't think having a stable public API
is on the critical path right now, but breaking all the command line tools is a
problem for making progress on stuff that is on the critical path.

I think this solution is preferable over reverting
b48584d3d0eb480943d72958104baf8e0e366074 that caused the breakage.

 
   /// Whether the compiler should throw as soon as it encounters a
   /// compilation warning.