Start trying to compile platform from unpatched sources.

pkg/front_end/test/fasta/compile_platform_test.dart

Index: pkg/front_end/test/fasta/compile_platform_test.dart
diff --git a/pkg/front_end/test/fasta/compile_platform_test.dart b/pkg/front_end/test/fasta/compile_platform_test.dart
new file mode 100644
index 0000000000000000000000000000000000000000..842fe7cec1c268defc54fcc061eaf26f7d605b3f
--- /dev/null
+++ b/pkg/front_end/test/fasta/compile_platform_test.dart
@@ -0,0 +1,58 @@
+// 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.md file.
+
+library fasta.test.compile_platform_test;
+
+import 'dart:io';
+
+import 'package:async_helper/async_helper.dart';
+
+import 'package:expect/expect.dart';
+
+import '../../tool/_fasta/compile_platform.dart' show compilePlatform;
+
+main(List<String> arguments) async {
+  await asyncTest(() async {
+    await withTemporyDirectory("compile_platform_test_", (Uri tmp) async {
+      String patchedSdk = Uri.base
+          .resolveUri(new Uri.file(Platform.resolvedExecutable))
+          .resolve("patched_sdk")
+          .toFilePath();
+      // This first invocation should succeed.
+      await compilePlatform(<String>[

[Siggi Cherem (dart-lang), 2017/08/24 19:27:02]

Alternatively, should we use the public APIs here instead?

We already do so in`patch_sdk`, so it would be good to bypass the helper scripts
and command-line argument parsing since it's not a relevant piece of this test.

[ahe, 2017/08/25 08:45:51]

I think it's a great idea to rewrite tool/_fasta/compile_platform.dart in terms
of the public API (I don't consider myself an owner of that task).

However, the main purpose of this test is to test that the tool works, not to
exercise the API. It is to address the lack of positive tests in 
pkg/front_end/test/fasta/tool_test.dart.

As soon as the tool stops crashing, I should probably switch to running it via
Process.

[Siggi Cherem (dart-lang), 2017/08/25 14:41:48]

OK - I misunderstood, I thought the goal was to have coverage for building the
platform with patch files, so we know that such functionality is working
correctly. Then maybe my suggestion is: when we start adding support for @patch,
it might be nice to have some unit test coverage that is testing that in
isolation if possible.

+        "-v",
+        patchedSdk,
+        tmp.resolve("platform.dill").toFilePath(),
+        tmp.resolve("platform-outline.dill").toFilePath(),
+      ]);
+      print("Successfully compiled $patchedSdk.\n\n");
+
+      try {
+        // This invocation is expected to throw an exception for now. Patching
+        // isn't fully implemented yet.
+        await compilePlatform(<String>[
+          "-v",
+          "sdk/",

[Siggi Cherem (dart-lang), 2017/08/24 19:27:02]

it might be worth checking first that this folder is resolved and exists?

Some bots run with `--use-sdk`, in which case the folder you want might be in a
different location (or we may want to not run in those bots)

[ahe, 2017/08/25 08:45:51]

That will lead to a different error and this test will fail. But all tests in
this directory are already skipped in that configuration.

+          tmp.resolve("platform.dill").toFilePath(),
+          tmp.resolve("platform-outline.dill").toFilePath(),
+        ]);
+      } on String catch (e) {
+        Expect.isTrue(
+            e.startsWith("A member with disambiguated name '_withType' "));
+        print("Failed as expected: $e");
+        return;
+      }
+      Expect.fail("Test didn't throw expected exception.");
+    });
+  });
+}
+
+withTemporyDirectory(String prefix, Future f(Uri tmp)) async {
+  Directory tmp = await Directory.systemTemp.createTemp(prefix);
+  try {
+    await f(tmp.uri);
+  } finally {
+    await tmp.delete(recursive: true);

[Siggi Cherem (dart-lang), 2017/08/24 19:27:02]

if we switch to use the public API, we should also be able to get rid of the
temp directory (we don't have to emit the files to disk, we would just create
the kernel program and toss it).

[ahe, 2017/08/25 08:45:51]

Yes, but that wouldn't test the tool. Perhaps we should have both tests.

[Siggi Cherem (dart-lang), 2017/08/25 14:41:48]

yes :)

+  }
+}