Add support for SDK outline in IKG.

pkg/front_end/lib/incremental_kernel_generator.dart

 // Copyright (c) 2017, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 import 'dart:async';
 
 import 'package:front_end/src/base/processed_options.dart';
 import 'package:front_end/src/incremental_kernel_generator_impl.dart';
 import 'package:front_end/src/fasta/compiler_context.dart';
 import 'package:kernel/kernel.dart';
@@ skipping 85 matching lines @@
   ///
   /// The initial "previous program state" is an empty program containing no
   /// code, and the initial set of valid sources is empty.  To obtain a kernel
   /// representation of the program, call [computeDelta].
   static Future<IncrementalKernelGenerator> newInstance(
       CompilerOptions options, Uri entryPoint,
       {WatchUsedFilesFn watch}) async {
     var processedOptions = new ProcessedOptions(options, false, [entryPoint]);
     return await CompilerContext.runWithOptions(processedOptions, (_) async {
       var uriTranslator = await processedOptions.getUriTranslator();
+      var sdkOutlineBytes = await processedOptions.loadSdkSummaryBytes();

[Siggi Cherem (dart-lang), 2017/08/07 19:12:52]

What do we want the default behavior to use a summary?

I'm guessing you want the default to be that we don't use a summary unless you
specified it explicitly, is that correct?

If so, this might not do quite what you want: if sdkSummary is not specified, we
will infer it based on the sdkRoot, so we might end up using a summary after
all.

I suggest that to address this we do something similar to what we did to have
different defaults in kernelForProgram and kernelForBuildUnit: 
 - add a flag to the ProcessedOptions constructor (we used `modularApi` before,
you might want to add `incremental`), we probably should switch to use
name-parameters, but I'm happy to address that in a separate change.
 - use the `incremental` option when inferring `ProcessedOptions.sdkSummary` 
 - add additional code in `validateOptions` to check for consistency of flags
and call it here. For example, we could add error messages if inputSummaries and
linkedSummaries are specified.
 - finally, add to the dartdoc in CompilerOptions.sdkSummary about the default,
and in CompilerOptions.inputSummaries and CompilerOptions.linkedDependencies
about what is not supported.

[scheglov, 2017/08/07 20:47:51]

Well, on this level it does not matter - IKG uses whatever values are returned
from ProcessedOptions.
It seems strange to me - implement inference for sdkSummary, but then heroically
disable it :-)
I thought that the motivation for this change was to make it possible to use SDK
outline in IKG.
How come we now disable it for IKG?

Or is it just to disable _inference_?
Then maybe it should be controlled by a special "allowSdkOutlineInference" flag.
Or maybe make it an explicit call inferSdkOutline() method.
This sounds good to me.

[Siggi Cherem (dart-lang), 2017/08/07 22:16:17]

Correct, this is about what do we want the default behavior to be if a user of
IKG doesn't provide any flags in CompilerOptions. If they explicitly provide the
URI to an sdk summary, we will use it, just like we do in all the other APIs.
We have something similar with the `compileSdk` option today. When compileSdk is
true: we don't infer the sdk summary, because your intent was to compile the
sdk, if compileSdk is false, we try to find a summary for you.

Note that `_ensureSdkDefaults()` method in ProcessedOptions might be similar to
what you were suggesting with `inferSdkOutline`. That's where we infer values
based on the options given to us. I prefer to keep it functional and not make it
procedural though: the value of sdkSummary shouldn't depend on whether you
called something in ProcessedOptions, but we should be able to compute it based
on the constructor arguments.


So the question is: what is the most common behavior we want for users of IKG?
If the most common behavior is to infer the location of the summary and use it,
then what you implemented here seems fine and we don't need to change the
defaults or add more public flags (only add errors for the other options that
IKG ignores). If the default should be to compileSdk from sources, then maybe
the fix should not be to change how we infer sdkSummary, but to make
`compileSdk` inferrable and infer true/false depending on the API.

[scheglov, 2017/08/07 23:34:11]

Flutter tools is the only known client of IKG, and it wants us to use SDK
outline.
So, this is the most common behavior, and we should infer outline location.

       return new IncrementalKernelGeneratorImpl(
-          processedOptions, uriTranslator, entryPoint,
+          processedOptions, uriTranslator, sdkOutlineBytes, entryPoint,
           watch: watch);
     });
   }
 }