CL https://codereview.chromium.org/1863053003/ added support for most
syntactic constructs in relation to generic methods/functions, and
this one adds the missing ones: Declarations of function typed arguments
with type parameters, declarations of generic local functions, and
declarations of generic literal function expressions. It also adds
support for `super` bounds, because they were discussed recently and
may be quite useful (and it turns out to be no problem to parse them).
Finally, a new test file is added to tests the additional constructs.
BUG=
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1878253002 .
This CL adds support for parsing and ignoring declarations of type
parameters on methods and functions, and passing type arguments to
method and function invocations. The type parameters thus declared do
not get a representation during static analysis, so any usage will
cause warnings about undefined types; hence, this CL transforms usage
of generic methods from syntax errors to static warnings. A followup
CL will eliminate the static warnings.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1863053003 .
When landed, CL 1789553003 turned out to cause bot failures because
some libraries outside the compiler are importing compiler libraries
which have been updated. For instance, the tests in 'compiler/dart2js'
depend on several internal elements of the 'dart2js' compiler.
This CL updates these external dependents to work with the modified
library structure and class APIs of the compiler. A small adjustment
was applied to 'dart2js_incremental' as well.
No further dependents are believed to exist: Grepping in sdk for
relevant imports does not reveal any further imports of any of the
libraries in the compiler where the "interface" has changed, and
external clients are not supported (that is, imports in arbitrary
github repositories may or may not break if they use the compiler
internals, but we do not support this type of dependency so we won't
do anything to protect them against that type of breakage).
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1864433004 .
In preparation for support for generic methods (with an associated
command line option), this CL introduces a `ParserOptions` class and
uses that to pass the existing option `enableConditionalDirectives` to
all parsers. With that, the addition of an `enableGenericMethodSyntax`
option will be concise and well localized.
It is necessary to keep a `ParserOptions` object in `Parsing`, because
that's the only convenient channel for providing the options to the new
`Parser` and `ClassElementParser` created from the top-level function
`parse` in 'partial_elements.dart', and a from
`PartialClassElement.parseNode`, respectively.
The `ParserOptions` class is located in 'parser.dart'; from the current
import structure the most natural choice might be to put it in
'element_listener.dart', but considering the nature of that file it
seems less natural: What does `ParserOptions` have to do with element
listeners? So I put it in 'parser.dart', even though this causes a few
additional import statements.
R=johnniwinther@google.com, sigmund@google.com
Review URL: https://codereview.chromium.org/1789553003 .
Before the mapping from HInstruction names to printed representations
used by the tracer was arbitrary. Change it to use the HInstruction
name with a colon separating the arguments from the instruction name.
The first colon on the line is recognized by the tool as delimiting
the opcode.
Seeing the precise structure of the IR is more important than
having human-writable surface syntax.
BUG=
R=sra@google.com
Review URL: https://codereview.chromium.org/1819833002 .
Johnni Winther