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 .
In the process I've made the constructors for Graph, LibraryCycleNode,
and LibraryNode public. I don't think this should be a problem, since
these are simple data structures, so there is no harm in allowing
clients to create them.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2617483007 .
I'm happy to split the style/refactorings as separate CLs if you prefer. Here is a summary of the changes:
- update the reported strings to match the names expected by our benchmark runners ("unlinked summaize + parse" => "unlinked_summarize")
- invert the benchmark results (like Paul did in 2551533003)
- stop counting input-size while scanning, count that separately once
- combine the multiple summarization steps into a single function
- clean up the logic that dispatches into each benchmark
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2602003002 .
This CL adds support for using sdk summaries when building kernel using the
front_end entrypoint. I didn't expose this functionality in the dartk binary,
I'm hoping we can delay doing so until we integrate dartk and front_end.
I also switched front_end/tool/perf.dart to use kernel_generator directly.
This makes some observable difference for small scripts, but not so much with large apps like dart2js. Makes sense considering that the sdk is about 2Mb, and dart2js is 6Mb of sources.
The most interesting number I got is building the a library kernel file (not the whole program) for a small hello-world script on a warmed up vm:
no summaries: 500ms
with summaries: 30ms
R=asgerf@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2562923002 .
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 .
In kernel, library import URIs now support an "app" scheme as an
alternative to the "file" scheme, representing a path relative to
the application root.
dartk takes an --app-root flag giving the application root. If none
is given, file URIs are used instead.
The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.
It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.
In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.
Source mapping URIs are not yet affected by this change.
R=kmillikin@google.com
Committed: https://github.com/dart-lang/sdk/commit/60adb852ad706ecf9424c77d47fa05583d543def
Review URL: https://codereview.chromium.org/2532053005 .
Reverted: https://github.com/dart-lang/sdk/commit/bb540416f27c39d75ee7f243899939fc37a2cd03
This removes third_party/pkg/kernel and changes dependencies to
refer to pkg/kernel instead.
Some status files are updated to reflect new test outcomes.
This required moving the following classes into front_end as well:
- CharSequenceReader
- SubSequenceReader
- JenkinsSmiHash
A small amount of the functionality of GatheringErrorListener and
AnalysisError had to be replicated, to avoid a dependency on the
analyzer package. In a future CL I will either refactor this code to
make it available to the rest of the front end, or, if
GatheringErrorListener and AnalysisError wind up getting moved into
the front end, I will un-do the replication.
I also took the liberty of addition functionality to JenkinsSmiHash to
make it easier to use.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2508483002 .
AnalysisError implements CompilationError but provides additional
services, such as extensibility via the `getProperty` method.
Note: CompilationError.location has been renamed to
CompilationError.span to avoid confusion (since its type is
`SourceSpan`, not `SourceLocation`).
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2498133002 .
Konstantin Shcheglov