Note: I removed the exception wrapping code as part of the migration.
Rationale: this function performs a small task and has been operating
successfully for a long time; removing the exception wrapping code
avoids making front_end dependent upon AnalysisException and
CaughtException at this time. In the unlikely event that an exception
occurs in this function, we still have many avenues available for
tracking down the problem: examine the stack trace of the exception,
isolate a repeatable test case (if the exception happened in
e.g. command-line analyzer), or reproduce the exception from file
state information recorded by the AnalysisDriver (if the exception
happened in analysis server).
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2668553002 .
Update the IncrementalKernalGenerator.computeDelta() method
with an optional "watch this source" callback.
This new callback notifies the caller when a source should be watched
for modifications, and when a source is no longer part of the program
and thus no longer needs to be watched.
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2653143003 .
There's no need to special case the handling of "dart:" URIs.
Eventually we will need the "allocate:" behavior for all URIs anyhow,
because we won't have a pre-traversal of the import graph to populate
the FileRepository.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2651193002 .
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 .
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 .
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 .
Peter von der Ahé