The new test is specifically for `dart2js --generic-method-syntax ..`,
executed programmatically using 'memory_compiler.dart'.
It verifies that each method type variable is treated as if it had
been an alias for `dynamic` (so the static analysis allows almost
all usages of these type variables, silently). Note that this behavior
is unlikely to be available with any other tools, and even `dart2js`
will behave differently when generic methods are implemented fully.
Hence, the new test will only be useful as-is during a transitional
period.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1939053002 .
Move serialization tests into subfolder
Move data files into data subfolders
Move tests with errors/warnings into quarantined subfolder
Skip packages/ folder in test
The latter three improves workflow in IntelliJ; providing error/warning free analysis of unittests (by exclusion of folders).
R=sigmund@google.com
Review URL: https://codereview.chromium.org/1934883002 .
This CL is a rebased and retested version of CL 1915123008,
'Implements support for ignoring method type arguments in
resolution'. That CL caused failures on dart2js-jsshell but it is
now confirmed that the failures were caused by another CL.
Review URL: https://codereview.chromium.org/1942763002 .
Extends `FunctionExpression` to hold the formal type variable
declaration syntax. Introduces `GenericElement` as a new superclass of
`TypeDeclarationElement`, allowing `FunctionElement` to have a getter
`typeVariables`. Changes `SignatureResolver.analyze` in several ways
to create and handle the new type variables. In order to avoid circular
ordering dependencies, introduced new scope classes such that the
function signatures can be computed without relying on themselves to
look up type variables (e.g., `FunctionSignatureBuildingScope`).
Finally, the mock_compiler and resolver_test.dart were adjusted to give
a `scope` argument to `new ResolverVisitor(..)` in order to get the
correct scopes in the new setup.
A few words about the approach:
The type of every method type parameter behaves as `dynamic`, because
its bound is (unconditionally, ignoring any bound syntax that might be
present) set to `const DynamicType()`. This preserves the property
that diagnostic messages about the type variables will refer to the
correct location in the source code.
Type arguments passed in send expressions are parsed but not added to
the abstract syntax and therefore not passed on to the resolution
phase; this means that all sends are treated as if they had no actual
type arguments, even when they do have them. Hence, actual method type
arguments are completely ignored.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1915123008 .
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 .
