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 .
With the new 'sendCachedToStream' option we can control that whether
cached analysis result is also reported into the 'results' stream when
it is desirable (when we do this to send analysis notifications from
the stream listener). Or not, when it is not desirable, e.g. when we
ask becaue we need the results unit for Quick Assists.
R=brianwilkerson@google.com
BUG= https://github.com/dart-lang/sdk/issues/30238
Review-Url: https://codereview.chromium.org/2989633002 .
This is tricky because there isn't a clean correspondence between
analyzer's AST (which reflects user syntax) and kernel representation.
For example:
f(args);
could be a call to a static function f, a method f in the current
class, or an invocation of a function-typed object stored in a
variable called f. ResolutionStorer operates on the kernel
representation, so it sees the difference, but ResolutionApplier
operates on the analyzer AST, so it does not. So we go to some extra
work to make sure a type is stored for f, regardless of whether f is a
function, method, or a variable. This requires some re-ordering logic
in ResolutionStorer, since the inferred type of f is not known until
after the args have been visited.
The implementation is not complete; currently the type that we store
in the first two cases is `dynamic` because the type inference
mechanism doesn't preserve enough information to allow us to determine
the correct type; this will be remidied in a future CL.
A similar situation occurs for:
x.m(args);
which could be a call to a method m in the object x, or an invocation
of a function-typed object returned by the getter m in the object x.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2984013002 .
The type inference engine doesn't even see parenthesized expressions
as a separate entity, since parentheses don't have any semantics. So
we just copy the static type from the enclosed expression.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2982323003 .
This CL propagates types from top level variable declarations into
analyzer ASTs.
This required adding a finishFields method to parser listeners (and a
corresponding method DietListener.listenerFinishFields which calls
it); this allows AnalyzerDietListener to thread the types through from
the BodyBuilder to the AstBuilder. This is similar to what we were
already doing for methods.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2987503003 .
Note, that we don't restore the original AST for StaticGet(s).
The original AST is not available in Kernel.
Instead we generate simple identifiers with correct elements.
It should be enough to compute constant values, although some clients
might have to adapt to the change.
R=paulberry@google.com
BUG=
Review-Url: https://codereview.chromium.org/2983773002 .
* 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 .
Just parts of library, defining unit and class for now.
This is enough to pass 15 tests out of 522 :-)
Although some of them are passing accidentally.
Only strong mode tests for now.
We don't compare with Analyzer elements created using Analyzer builders,
because these builders will go away. But we miss testing for things
like name offsets.
R=ahe@google.com, paulberry@google.com, sigmund@google.com
BUG=
Review-Url: https://codereview.chromium.org/2980863003 .
This CL propagates types for simple variable declarations into analyzer ASTs.
Note that for a variable declaration like `int x` we need to store two
pieces of information: the element pointed to by `int`, and the type
of `x`. This CL handles the latter. The former will wait until we
have enough of the element model built that we have an element to
point to.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2980053002 .
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 .
Konstantin Shcheglov