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 .
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 .
In the long run, pkg/front_end/src/base is intended to contain code
that is useful to many components of the front end.
In this initial implementation, it contains:
- Source and the classes it references
- ErrorCode, ErrorSeverity, and ErrorType
- SyntacticEntity
Note that AnalysisTarget is included (even though strictly speaking it
is part of the analyzer task model) because it was too hard to
disentangle from Source.
Note that Token classes remain in pkg/front_end/src/scanner for now; I
plan to reorganize them at the time the parser is moved into the front
end.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2486923007 .
These existed as an effort to avoid causing breaking changes in the
analyzer package, but it turns out that the analyzer package already has
breaking changes in progress, so there is no benefit.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2491593003 .
Several support classes also had to move to front_end along with the
scanner. Some of these support classes arguably don't belong to the
scanner itself, since they have other uses (e.g. SyntacticEntity,
ErrorCode, ErrorSeverity, ErrorType, and StringUtilities). They will
be reorganized into a more appropriate location in future CLs, at the
time that they become needed by other components of the front end.
In order to avoid dragging in a lot of dependencies, the following
changes were made:
1. Scanner no longer reports errors through Source and
AnalysisErrorListener objects passed to the constructor. Instead, it
provides an abstract reportError() method which clients may override
to perform error reporting in any way they wish. Analyzer contains an
override of Scanner that mimics the old behavior in order to maintain
compatibility.
2. Static members of ErrorCode (`values` and `byUniqueName`) have been
moved to top level, and remain in analyzer. To maintain
compatibility, these static members remain in ErrorCode (as deprecated
members that simply wrap the implementations in analyzer). This means
we have a reverse dependency (front_end depends on analyzer), but this
dependency will go away as soon as we publish the next breaking change
release of analyzer.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/2486873003 .
This required some small changes to the API contract.
Note that the tests use supermixins. I'm assuming that supermixin
functionality will be available on all platforms by the time this is
needed. If not, I will be happy to rewrite them.
R=scheglov@google.com, sigmund@google.com
Review URL: https://codereview.chromium.org/2471283002 .
Sigmund Cherem