Disable printing in kernel-driver

pkg/front_end/lib/src/incremental/kernel_driver.dart

Index: pkg/front_end/lib/src/incremental/kernel_driver.dart
diff --git a/pkg/front_end/lib/src/incremental/kernel_driver.dart b/pkg/front_end/lib/src/incremental/kernel_driver.dart
index 6a6c236c17f39e5e28ddefe5de0326828f57c19d..0b350ac0167bf7f4a7732d94a4591871f6d0356d 100644
--- a/pkg/front_end/lib/src/incremental/kernel_driver.dart
+++ b/pkg/front_end/lib/src/incremental/kernel_driver.dart
@@ -7,6 +7,8 @@ import 'dart:async';
 import 'package:front_end/file_system.dart';
 import 'package:front_end/src/base/api_signature.dart';
 import 'package:front_end/src/base/performace_logger.dart';
+import 'package:front_end/src/fasta/compiler_command_line.dart';
+import 'package:front_end/src/fasta/compiler_context.dart';
 import 'package:front_end/src/fasta/dill/dill_library_builder.dart';
 import 'package:front_end/src/fasta/dill/dill_target.dart';
 import 'package:front_end/src/fasta/kernel/kernel_target.dart';
@@ -113,7 +115,7 @@ class KernelDriver {
   ///
   /// Otherwise the driver will compute new kernel files and return them.
   Future<KernelResult> getKernel(Uri uri) async {
-    return await _logger.runAsync('Compute delta', () async {
+    return await runWithFrontEndContext('Compute delta', () async {
       await _refreshInvalidatedFiles();
 
       // Ensure that the graph starting at the entry point is ready.
@@ -146,6 +148,16 @@ class KernelDriver {
     });
   }
 
+  Future<T> runWithFrontEndContext<T>(String msg, Future<T> f()) async {
+    return await CompilerCommandLine.withGlobalOptions("", [""],

[scheglov, 2017/07/14 15:49:17]

The name CompilerCommandLine does not make sense in KernelDriver.
It not a command line compiler, and Fasta is not a command line compiler.

And in general using global state smells.
This in particular means that we cannot have parallel execution of
KernelDriver(s).
But we might have to, because we create AnalysisDriver (and so will
KernelDriver) for each project in Analysis Server. And because Fasta is
asynchronous, we cannot guarantee that there wouldn't be execution flow switch
from one driver to another.

[Siggi Cherem (dart-lang), 2017/07/14 16:34:04]

Completely agree - this is exactly what I'm working on fixing next: when I say I
want to unify ProcessedOptions and CompilerContext is also to get rid of
CommandLine* objects.
Note that this is actually a misnomer here. Internally this is using a
zone-scope, everything within this call (including async calls) are captured by
a zone that contains the context. It is equivalent to adding a Context argument
and passing it around everywhere.

Today there is a default context, and that's why we didn't notice this so far.
In my refactor I'll get rid of the default context as well, so we know when we
are invoking fasta without a required context (which would be equivalent to not
passing an argument).

To support parallel calls to fasta, that would be completely fine. We can create
and store the context objects separately and reuse them if we are invoking fasta
twice on the same context. If you need to use run fasta with different context
options in parallel, that would also work: each call will have it's own zone
with its own context in scope.

Hope this addresses your concerns. Happy to chat more over VC about this.

+        (CompilerContext context) {
+      context.options.options["--target"] = _target;
+      context.options.options["report"] = (message, severity) {};
+      context.options.options["reportWithoutLocation"] = (message, severity) {};
+      return _logger.runAsync(msg, f);
+    });
+  }
+
   /// The file with the given [uri] might have changed - updated, added, or
   /// removed. Or not, we don't know. Or it might have, but then changed back.
   ///