Implements support for ignoring method type arguments in resolution.

Implements support for ignoring method type arguments in resolution.

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

Committed: https://github.com/dart-lang/sdk/commit/e44e667ca7a57eb98050b43c3d6b084c1604a3bd

[eernst, 2016-04-28 14:57:04]

eernst@google.com changed reviewers:
+ johnniwinther@google.com

[eernst, 2016-04-28 14:57:05]

First dart2js with reasonably complete support for generic method syntax: parses
the new constructs except typedef-of-generic (whose syntax has not been chosen),
ignores actual type arguments in sends, and considers formal type variables to
be `dynamic` in their scope.

Not yet included: A test using type variables incorrectly (for example, `new
T()`), showing that diagnostics are meaningful, and refer to the right source
code location.

[Johnni Winther, 2016-04-29 07:21:06]

lgtm

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/elemen...
File pkg/compiler/lib/src/elements/elements.dart (right):

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/elemen...
pkg/compiler/lib/src/elements/elements.dart:1571: /// The class, typedef,
function, or method on which this type variable is
or function typed parameter

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/resolu...
File pkg/compiler/lib/src/resolution/members.dart (right):

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/resolu...
pkg/compiler/lib/src/resolution/members.dart:1879: if
(!Elements.hasAccessToTypeVariables(enclosingElement) &&
Move the check of `element.typeDeclaration is TypeDeclarationElement` into
`hasAccessTypeVariables` (probably by changing it to `hasAccessTypeVariable` and
giving it the [TypeVariableElement] instead)

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/resolu...
File pkg/compiler/lib/src/resolution/scope.dart (right):

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/resolu...
pkg/compiler/lib/src/resolution/scope.dart:93: * class hierarchy. In all other
cases [ClassScope] is used.
It is also used for resolving typedef signatures.

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/resolu...
File pkg/compiler/lib/src/resolution/signatures.dart (right):

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/resolu...
pkg/compiler/lib/src/resolution/signatures.dart:311: new
List.generate(nodes.slowLength(), (int index) {
Use dartfmt on the code (i.e. this seem like a bad indentation)

https://codereview.chromium.org/1915123008/diff/1/tests/compiler/dart2js/mock...
File tests/compiler/dart2js/mock_compiler.dart (right):

https://codereview.chromium.org/1915123008/diff/1/tests/compiler/dart2js/mock...
tests/compiler/dart2js/mock_compiler.dart:233: scope: new
MockTypeVariablesScope(
Why is this necessary?

[eernst, 2016-04-29 13:24:50]

Review response.

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/elemen...
File pkg/compiler/lib/src/elements/elements.dart (right):

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/elemen...
pkg/compiler/lib/src/elements/elements.dart:1571: /// The class, typedef,
function, or method on which this type variable is
On 2016/04/29 07:21:06, Johnni Winther wrote:
> or function typed parameter

Done.

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/resolu...
File pkg/compiler/lib/src/resolution/members.dart (right):

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/resolu...
pkg/compiler/lib/src/resolution/members.dart:1879: if
(!Elements.hasAccessToTypeVariables(enclosingElement) &&
On 2016/04/29 07:21:06, Johnni Winther wrote:
> Move the check of `element.typeDeclaration is TypeDeclarationElement` into
> `hasAccessTypeVariables` (probably by changing it to `hasAccessTypeVariable`
and
> giving it the [TypeVariableElement] instead)

Done.

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/resolu...
File pkg/compiler/lib/src/resolution/scope.dart (right):

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/resolu...
pkg/compiler/lib/src/resolution/scope.dart:93: * class hierarchy. In all other
cases [ClassScope] is used.
On 2016/04/29 07:21:06, Johnni Winther wrote:
> It is also used for resolving typedef signatures.

Done.

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/resolu...
File pkg/compiler/lib/src/resolution/signatures.dart (right):

https://codereview.chromium.org/1915123008/diff/1/pkg/compiler/lib/src/resolu...
pkg/compiler/lib/src/resolution/signatures.dart:311: new
List.generate(nodes.slowLength(), (int index) {
On 2016/04/29 07:21:06, Johnni Winther wrote:
> Use dartfmt on the code (i.e. this seem like a bad indentation)

Done.

https://codereview.chromium.org/1915123008/diff/1/tests/compiler/dart2js/mock...
File tests/compiler/dart2js/mock_compiler.dart (right):

https://codereview.chromium.org/1915123008/diff/1/tests/compiler/dart2js/mock...
tests/compiler/dart2js/mock_compiler.dart:233: scope: new
MockTypeVariablesScope(
On 2016/04/29 07:21:06, Johnni Winther wrote:
> Why is this necessary?

I managed to remove one of the two usages of this kind of scope (in
`resolverVisitor()`). Removing the other one causes >13 tests to fail in
`tools/test.py --checked --mode=release dart2js`. The reason is that there is a
mock function `function` whose enclosing scope structure differs from the scope
structure of all the functions created in the compiler; it seems reasonable to
stick with the compiler style setup also in the context of mock entities.

[eernst, 2016-04-29 17:46:22]

Description was changed from

==========
Implements support for ignoring method type arguments in resolution.

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.
==========

to

==========
Implements support for ignoring method type arguments in resolution.

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

Committed:
https://github.com/dart-lang/sdk/commit/e44e667ca7a57eb98050b43c3d6b084c1604a3bd
==========

[eernst, 2016-04-29 17:46:24]

Committed patchset #4 (id:60001) manually as
e44e667ca7a57eb98050b43c3d6b084c1604a3bd (presubmit successful).