With the experiment flag on, will properly parse the `in`/`out`/`inout`
keywords. Without it, will issue an error regarding the flag. First CL
for parsing, syntax support, no AST work yet.
Keywords only parse correctly for classes and mixins.
See test `variance_disabled_syntax_test.dart`.
Change-Id: I37d765804fa0752512abf52fa44456a173087ef0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/117929
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Currently, fasta synthetically closes open braces until it finds
a match for the current closing brace. This works most of the time,
but provides less than optimal recovery in some common cases.
For example, given the following
class { foo()){print(a);} var a = 'hello'; }
the current brace recovery method fails to find any match for the
second closing parenthesis and synthetically closes the class
causing the rest of the file to be parsed as outside the class.
With this CL, fasta still synthetically closes open braces when it finds
a match for the current closing brace, but if there is no match, then
it just skips over the extra closer and continues. This approach dramatically
improves recovery in many cases where there is an extra closing parenthesis
or extra closing square bracket. In the example above, fasta parses
everything after the second closing parenthesis inside the class.
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2981343002 .
This updates the fasta scanner to translate the remaining
previously untranslated error codes so that they will be seen
by the analyzer when the fasta scanner is used by analyzer.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2923113002 .
* improve fasta interpolation recovery by adding closing brace
for unterminated string
* update analyzer scanner test because fasta does not support
does not support \r line endings
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2910583002 .
Retrying https://codereview.chromium.org/2803563003
* update analyzer.Keyword list to include all of the fasta keywords
* enhance the analyzer scanner keyword table to handle uppercase
keywords such as "Function"
* update analyzer's parser to process the new KeywordTokens
* fix analyzer error verification
* update translation of fasta <--> analyzer tokens
* update tests and cleanup analyzer warnings
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2799133003 .
* 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 .
* 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 .
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 .
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 .
Johnni Winther