This adds a class CanonicalName that can represent a library, class,
or member. All references now go through a Reference object, which is
linked to both the AST node and its CanonicalName, so either can be
created first.
dartk now accepts multiple input files:
- If multiple dart files are given, they are all compiled.
- If multiple binaries are given, they are linked together.
Mixed dart and binary input is not supported by dartk.
dartk now has a flag --include-sdk which includes the entire SDK in
the output. This is so the SDK can be compiled alone and then linked.
Example of compiling separately and then linking:
dartk foo.dart -o foo.dill
dartk main.dart -o main.dill
dartk --include-sdk -o sdk.dill
dartk main.dill foo.dill sdk.dill --target=vm --link -o program.dill
dartk still has incredibly slow cold start due to the analyzer loading
the dart sdk, so this does not actually speed things up at the moment.
BUG=
R=ahe@google.com, kmillikin@google.com, kustermann@google.com, sigmund@google.com
Review-Url: https://codereview.chromium.org/2665723002 .
This required adding some scanner tests in order to validate the translation.
Note that the Fasta scanner considers "<", ">", and ">>" to be
grouping tokens (with special rules to avoid problems when "<" is used
to mean "less than"); analyzer does not. The translation does not
handle this correctly yet.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2690073003 .
This will be needed in order to integrate Fasta into the existing
analyzer codebase, because the analyzer task model considers the
parser and scanner to be separate black boxes with an analyzer token
stream in between. In order for Fasta to be able to drop into those
black boxes, we will need to be able to convert Fasta tokens to
analyzer tokens after scanning, and then back to Fasta tokens prior to
parsing.
Tested via a "round trip" test that converts the analyzer token stream
into a Fasta token stream and then back.
Note that the transformation is not perfect; it currently fails to
recreate error tokens and it fails to hook up the connection between a
BeginGroup token and the corresponding end token. But it is enough to
be able to pass tests for now. It will be improved (and tests will be
expanded) in future CLs.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2689733003 .
This logic was initially only used in scanner_fasta_test, however we
are going to need it for other tests (some of which are outside of the
Fasta package), and on a short term basis we may want to use it to
help integrate pieces of Fasta with pieces of the analyzer codebase.
So it needs to be somewhere that's accessible outside of
pkg/front_end/test.
I performed some trivial improvements during the move (such as using
Token.info.kind in preference to "is" checks, and identifying the end
of the input by looking for a nearby EOF token).
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2686363002 .
Previously, the scanner tests and the Fasta implementation had
duplicate logic for translating Fasta tokens to analyzer tokens. This
CL unifies the translation logic, and fills in some functionality that
was missing from the Fasta translation logic.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2682423003 .
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 .
Paul Berry