Failing tests are currently marked with "@failingTest" to prevent
breaking buildbots.
I've marked the issues I'm aware of with "TODO(paulberry,ahe)". Peter
and I need to triage these issues--some of them may not be necessary
to fix due to the fact that fasta replaces the parser as well. We
will follow up with CLs that either fix the issues or remove the TODO
comments as appropriate.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2676083002 .
I populated subpackageRules with the set of dependencies that are
needed in order to make the tests pass. Hopefully we can eliminate
some of these dependencies in the future.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2674463002 .
This implementation is based on the existing kernel and analysis
driver logic, using proxy classes to account for interface
incompatibilities between those components. In future CLs, I
hope we can (a) move the necessary analysis driver logic into
front_end, and (b) reduce or eliminate the number of proxy
classes needed.
This CL represents the very first inklings of functionality; all that
is confirmed to work at this point is compilation of a single source
file containing an empty `main` method.
R=danrubel@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2624193003 .
With the simplification to PhysicalFileSystem introduced in
fef4569eb5, the URI "/foo.dart" is now
uniformly treated as equivalent to "file:///foo.dart", even on
Windows. (At the time the file is read, the file will be located on
the current drive). This is consistent with what we do for relative
paths.
TBR=sigmund@google.com
Review-Url: https://codereview.chromium.org/2634543003 .
- Use Uri.base.resolveUri() to do all necessary normalization and
conversion to absolute paths.
- Store a URI in _PhysicalFileSystemEntity rather than a path.
- Use `new io.File.fromUri(...)` to access the physical files.
- Fix some minor bugs in physical_file_system_test.dart.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2622423003 .
This carries a number of benefits:
- It allows the front end to trivially support schemes other than
"file:" (e.g. "http:") by allowing the client to supply a FileSystem
implementation that handles them.
- It is more consistent with the functionality of the ".packages" file
(which allows packages to map to any kind of URI).
- It allows the "bazel root" feature to be rewritten to use a magic
scheme rather than a magic path. (This eliminates concerns about
the magic path overlapping with a user's use case). Note that this
feature has been renamed to "multi root" since it is sufficiently
generic to be applicable to build systems other than Bazel.
- It reduces the risk of forgetting to use the front end's FileSystem
abstraction to access the file system, since the native file system
interfaces do not accept URIs.
R=danrubel@google.com
Review-Url: https://codereview.chromium.org/2614063007 .
This is intended to be used in situations where computing dependencies
and/or evaluating nodes is an asynchronous operation. (For example,
when performing a compilation, computing dependencies of a library
requires file I/O to read the files constituting the library;
evaluating a library cycle might potentially be performed
asynchronously by a separate isolate).
At the moment the implementation is nearly the same as that of
dependency_walker.dart, except asynchronous. In future CLs I will
look into allowing computeDependencies(), evaluate(), and
evaluateScc() to operate in parallel.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2552383002 .
Paul Berry