Rather than have multple fine grained error codes for each type
of modifier in each situation, this CL adds a new analyzer
ParserErrorCode.EXTRANEOUS_MODIFIER parallel to the fast parser
error code and updates the AstBuilder to generate that error
rather than ParserErrorCode.ABSTRACT_CLASS_MEMBER.
My goal is to review each analyzer error code similar to
ParserErrorCode.ABSTRACT_CLASS_MEMBER and map each to the same
ParserErrorCode.EXTRANEOUS_MODIFIER error code.
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2999303002 .
Refactor the AstBuilder to use scriptTag, directives, and declarations
fields rather than pushing top level nodes on a generic stack
and later popping and sorting objects from the that generic stack.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2995963002 .
The fasta parser generates begin/end event pairs such as
[beginCompilationUnit] and [endCompilationUnit].
Each event should be generated "within" a "higher level" begin/end event pair,
except for [beginCompilationUnit] and [endCompilationUnit],
which should not be generated within any begin/end event pair.
This CL updates the fasta test listener and associated test code to assert that
[endTopLevelDeclaration] is generated within or is enclosed by
a begin/end "CompilationUnit" event pair, and that the [beginCompilationUnit]
and [endCompilationUnit] events are not enclosed by any begin/end event pairs.
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2993833002 .
This updates the analyzer parser compatibility tests to check for
error codes. Any test that was passing but failed as a result of these
changes was updated to continue passing and a duplicate test'2' added
in the subclass and marked as failing.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2990003002 .
This CL is identical to the reverted CL 2990703002 which implements
syntactic support for generalized void in the analyzer, plus two bug
fixes in pkg/analyzer/test/generated/parser_test.dart and
pkg/analyzer_cli/test/error_test.dart. In the former, a test on parsing
`void,` was changed to expect an error: _isTypeIdentifier on a lone
`void` will no longer return true, which is necessary because `void`
can now be used as a type annotation alone. Another test on `void x`
was added, which produces the behavior previously seen for `void,`.
In error_test, the error which is used throughout was changed from
`void foo;` to `var int foo;` (because the former is no longer an
error).
Review-Url: https://codereview.chromium.org/2992623002 .
Changed the analyzer parser to accept usages of `void` which were
previously rejected as syntax errors: `void` can now be the type
annotation for a variable or parameter, and it can be an actual type
argument.
Removed affected error codes like VOID_PARAMETER, VOID_VARIABLE,
VOID_RETURN_FOR_GETTER and associated declarations (like checking
functions), and adjusted test cases to expect success rather than
compile time errors.
Adjusted generalized_void_syntax_test.dart (it had real errors like
`final` variables with no initializer etc. that were not detected
when tools would just reject the file as syntactically wrong).
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2990703002 .
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 .
* make _end(optional: false) which uncovered unbalanced begin/end pairs
* update and document top level member events
* rename handleSwitchCase to endSwitchCase to better align with beginSwitchCase
* update and document begin/endFor/endForIn events
* cleanup test listener
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2980043003 .
This code is no longer needed because we no longer run the front end
in "kompile" mode.
Also remove the old expectations files used by the "kompile" tests.
I will remove more code in future CLs.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2980883003 .
This CL lays the groundwork for integrating the front end with
analyzer by creating a mechanism to copy resolution and type inference
information (produced by the front end's type inference engine) into
analyzer ASTs (produced by AstBuilder).
The general technique is to parse each function twice: once with
BodyBuilder as a listener and once with AstBuilder as a listener. The
BodyBuilder generates a kernel representation of the function, but
this isn't used; instead, type inference and resolution information is
captured using ResolutionStorer (which is a TypeInferenceListener).
Later, this information is applied to the analyzer AST generated by
AstBuilder using ResolutionApplier (which is an analyzer AST visitor).
At the moment the intermediate data exchanged between ResolutionStorer
and ResolutionApplier is simply a list of types (one for each
subexpression, in a post-order traversal of the program syntax). For
debugging and validation purposes, this is augmented with a list of
file offsets, so that if the ResolutionStorer and ResolutionApplier
get out of sync we can diagnose the problem easily.
In later CLs, more data will need to be exchanged between
ResolutionStorer and ResolutionApplier (e.g. a list of elements to
which identifiers are resolved).
This CL doesn't tackle the problem of translating between the kernel
and analyzer representation of types; for now we simply map each type
to `dynamic`. This is sufficient for early development, since it is
still enough to let us verify that ResolutionStorer and
ResolutionApplier stay in sync.
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2981693002 .
Brian Wilkerson