Implement URI resolution in the front end.

pkg/front_end/lib/src/base/uri_resolver.dart

Index: pkg/front_end/lib/src/base/uri_resolver.dart
diff --git a/pkg/front_end/lib/src/base/uri_resolver.dart b/pkg/front_end/lib/src/base/uri_resolver.dart
new file mode 100644
index 0000000000000000000000000000000000000000..34b0e1754a863edfa0175ce512251da3b2917d6f
--- /dev/null
+++ b/pkg/front_end/lib/src/base/uri_resolver.dart
@@ -0,0 +1,73 @@
+// 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.
+
+import 'package:path/path.dart' as p;
+
+/// The class `UriResolver` implements the rules for resolving URIs to file
+/// paths.
+class UriResolver {

[Brian Wilkerson, 2016/12/13 19:13:54]

I don't know whether this class needs to support the 'http' scheme, but I
believe that the VM does currently have support for it.

[Paul Berry, 2016/12/13 19:22:34]

I don't know either.  I've added a TODO for now.  I will follow up with VM
folks.

+  /// A map from package name to the file URI of the "lib" directory of the
+  /// corresponding package.  This is equivalent to the format returned by
+  /// the "package_config" package's parse() function.
+  final Map<String, Uri> packages;

[Brian Wilkerson, 2016/12/13 19:13:54]

I'm probably missing context here, but I don't believe this will work for the
Bazel case because we can't provide a simple map that allows us to locate
generated files. Is that case going to be supported?

[Paul Berry, 2016/12/13 19:22:34]

The plan for how to support the Bazel case is that the URI will be resolved to a
path of the form "file:///bazel-root/a/b/c.dart".  Then, a special
implementation of the FileSystem class will be used which understands that file
paths of this form should be looked up in a variety of Bazel-specific locations
until the first file which exists is found.

The advantages of this scheme are that is keeps Bazel-specific logic isolated
from the rest of the front end, and it avoids requiring file system access in
order to do URI resolution (so URI resolution remains fast even if files are
located on a network file system).  It's also consistent with what happens in
dart2js.

+
+  /// A map from SDK library name (e.g. `core` for `dart:core`) to the file URI
+  /// of the defining compilation unit of the SDK library.
+  final Map<String, Uri> sdkLibraries;
+
+  /// The path context which should be used to convert from file URIs to file
+  /// paths.
+  final p.Context pathContext;
+
+  /// The URI scheme used for "package" URIs.
+  static const PACKAGE_SCHEME = 'package';
+
+  /// The URI scheme used for "dart" URIs.
+  static const DART_SCHEME = 'dart';
+
+  /// The URI scheme used for "file" URIs.
+  static const FILE_SCHEME = 'file';
+
+  UriResolver(this.packages, this.sdkLibraries, this.pathContext);
+
+  /// Converts a URI to a file path.
+  ///
+  /// If the given URI is valid, and of a recognized form, returns the file path
+  /// it corresponds to.  Otherwise returns `null`.  It is not necessary for the
+  /// URI to be absolute (relative URIs will be converted to relative file
+  /// paths).
+  ///
+  /// Note that no I/O is performed; the file path that is returned will be
+  /// independent of whether or not any particular file exists on the file
+  /// system.
+  String resolve(Uri uri) {

[Siggi Cherem (dart-lang), 2016/12/13 20:25:57]

General question about the design here: how much do we expect to use paths and
URIs in the rest of frontend? What if we use URIs everywhere except in
FileSystem? If so, this could become a URI => URI (output guaranteed to be a
file:// URI)

[Paul Berry, 2016/12/13 21:15:17]

Hmm, I like your idea.  Taking it a step further, maybe we should drop the
requirement that the output is guaranteed to be a file URI--that would allow us
to support things like "http" URIs by putting the logic for fetching from http
into the FileSystem abstraction.

I'm going to commit the code as is so that I can make forward progress, but I'll
revisit the question soon.

+    Uri fileUri;
+    if (uri.scheme == FILE_SCHEME) {
+      fileUri = uri;
+    } else {
+      var path = uri.path;
+      var slashIndex = path.indexOf('/');
+      String prefix;
+      String rest;
+      if (slashIndex >= 0) {
+        prefix = path.substring(0, slashIndex);
+        rest = path.substring(slashIndex + 1);
+      } else {
+        prefix = path;
+        rest = '';
+      }
+      Uri libUri;
+      if (uri.scheme == PACKAGE_SCHEME) {
+        if (slashIndex < 0) return null;
+        libUri = packages[prefix];
+      } else if (uri.scheme == DART_SCHEME) {
+        libUri = sdkLibraries[prefix];
+      }

[Siggi Cherem (dart-lang), 2016/12/13 20:25:57]

maybe add an else to throw for unsupported schemes?

[Paul Berry, 2016/12/13 21:15:17]

Actually the behavior I'm aiming for is that unsupported schemes cause us to
return `null`--that allows the client to handle all mal-formed URIs using the
same logic.

As with the above comment, I'm going to commit as is for now, but I'll revisit
it soon.

+      if (libUri == null) return null;
+      fileUri = libUri.resolve(rest);
+      if (fileUri.scheme != FILE_SCHEME) return null;

[Siggi Cherem (dart-lang), 2016/12/13 20:25:57]

I'd also be OK validating that the map is initialized correctly instead.

[Paul Berry, 2016/12/13 21:15:17]

Acknowledged.

+    }
+    return pathContext.fromUri(fileUri);
+  }
+}