Initial API for the Dart front_end package.

pkg/front_end/lib/summary_generator.dart

Index: pkg/front_end/lib/summary_generator.dart
diff --git a/pkg/front_end/lib/summary_generator.dart b/pkg/front_end/lib/summary_generator.dart
new file mode 100644
index 0000000000000000000000000000000000000000..3a60354dfa2ef16ca650c715505027c94c11dfa6
--- /dev/null
+++ b/pkg/front_end/lib/summary_generator.dart
@@ -0,0 +1,31 @@
+// Copyright (c) 2016, 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.
+
+/// Defines the front-end API for converting source code to summaries.
+library front_end.summary_generator;
+
+import 'dart:async';
+import 'options.dart';
+
+/// Creates a summary representation of the build unit whose source files are in
+/// [sources].
+///
+/// Intended to be a part of a modular compilation process.
+///
+/// [sources] should be the complete set of source files for a build unit
+/// (including both library and part files).
+///
+/// The summarization process is hermetic, meaning that the only files which
+/// will be read are those listed in [sources], [Options.inputSummaries], and
+/// [Options.sdkSummary].  If a source file attempts to refer to a file which is
+/// not obtainable from these paths, that will result in an error, even if the
+/// file exists on the filesystem.
+///
+/// Any `part` declarations found in [sources] must refer to part files which
+/// are also listed in [sources], otherwise an error results.  (It is not
+/// permitted to refer to a part file declared in another build unit).
+///
+/// The return value is a list of bytes to write to the summary file.

[Siggi Cherem (dart-lang), 2016/10/17 16:27:29]

Not sure yet about the use cases, but are there situations where it could be
useful to return the in-memory summary representation here? (so we would do the
encoding to bytes separately?)

[Paul Berry, 2016/10/17 17:04:27]

At the moment I can't imagine a scenario where it will be necessary, and even if
it does become necessary I believe the performance impact of extra
serialization/deserialization would be small.  I'd prefer to stick with the
simpler API for now.

+Future<List<int>> summarizeBuildUnit(Options options, List<Uri> sources) =>
+    throw new UnimplementedError();