This was de-duped in 02573b3caa, however
there's a problem: In order to share type inference and error
detection logic between Fasta's AstBuilder and BodyBuilder classes,
Fasta's use of the accessors needs to be rewritten to make use of the
shadow hierarchy (see
pkg/front_end/lib/src/fasta/builder/shadow_ast.dart), which kernel
shouldn't have to depend on.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2794013003 .
* finish making fasta tokens implement analyzer token API
* move a couple things from analyzer into front_end
* Scanner useFasta flag
* SyntheticKeywordToken
* SyntheticStringToken
* add a fastaSupportsGenericMethodComments flag to more easily find
all of the places in the code that need to be addressed
when this functionality is added or dropped
* initialize linestarts in scanner adapter
* cleanup analyzer hints
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2794653002 .
* add new SyntheticSymbolToken class
* whenever fasta inserts a closer ( '}', ']', ')' ) that is not part
of the original source, ensure that the inserted closer is
synthetic (isSynthetic returns true) and in the token stream
* make EOF a synthetic token
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2777153002 .
Relative paths in a depsfile are interpreted by ninja relative to the
current working directory which in a GN build is the root of the build
directory ($root_build_dir in GN terms). When doing a
cross-compilation, this is different from the root of the output
directory ($root_out_dir in GN terms) for all builds other than the
target. This fixes the computation of depsfile entries so that they are
always relative to the current working directory.
Concretely, this means incremental builds in Fuchsia do not always
rerun the patch_sdk step for the host, shaving 12+ seconds off of no-op
builds.
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2776323002 .
* cleanup defaultRecoveryStrategy next/previous and eof
* add SymbolToken.eof() constructor to ensure that EOF tokens
are correctly self referencing
* add fasta.scanString method to match scan method
* add fasta.ScannerResult.hasErrors field
so that scan and scanString callers can quickly check for errors
* new scanner replacement test
which scans using fasta then asserts as if it were from analyzer
* improve SymbolToken.toString() for EOF
* update analyzer test :: fasta scanner considers "<" to be an opener
* extract and move translateErrorToken into front_end
* address comments in https://codereview.chromium.org/2763833002R=ahe@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2767083002 .
In the long run, this shadow hierarchy is intended to be used both for
kernel and analyzer ASTS; this should allow a single BodyBuilder class
to build either a kernel or an analyzer AST depending on which factory
it's connected to.
For now we only have a kernel shadow hierarchy, and it's incomplete,
so the code is not yet used. I intend to follow up with CLs that
complete the implementation and hook it up to BodyBuilder.
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2769723004 .
Peter von der Ahé