implement generic functions/methods in other AST nodes besides MethodInvocation #25175
Comments
jmesserly
added
P1
jmesserly
changed the title
jmesserly
changed the title
|
btw feel free to edit the first message, not sure if I've captured all of the missing features |
|
Tear offs seem to be working. I think the partial instantiation is lower priority, particularly given that I think the work involved will be larger. I'll work on getting function expression invocation working. |
|
@leafpetersen if you don't mind I'll take this, I think it will be pretty easy to fix to FunctionExpressionInvocation after the cleanup in https://codereview.chromium.org/1568643002/ |
|
This might belong in a different bug, but I just noticed we don't handle this case correctly: int lambdaCall = (/*<T>*/(/*=T*/ e) => e)/*<int>*/(3); |
|
Sure, all yours. |
|
Hmmm, actually it looks like we don't support that lambda form? In which case it's a bug in the error handling, as we should disallow type parameters there. |
Introduces MethodInvocation.staticInvokeType to track the type of this invocation. This provides a natural place to store the instantiated generic function type. We then use this type when we are computing corresponding parameters or return types. As a result we do not need FunctionMember, and some of the code around generics becomes simpler/more uniform. This approach should be a straightforward way to add support for generics in FunctionExpressionInvocation, in a follow up (see issue #25175). Also renames "boundTypeParameters" to "typeFormals". "formals" and "actuals" is a pretty common way to describe these, I'm not sure why I didn't think of that better name originally. :) Also removes broken ParameterMember.== that I had added in a previous CL. And the broken FunctionTypeImpl.originalFunction/instantiatedTypeArguments getters. Finally, this fixes #23252 in the process of adding this. The return type of a "call" method was not being statically analyzed if the target was a VariableElement. R=brianwilkerson@google.com, leafp@google.com Review URL: https://codereview.chromium.org/1568643002 .
|
Tearoffs were fixed in https://codereview.chromium.org/1568643002 |
fixes part of #25175 R=brianwilkerson@google.com, leafp@google.com Review URL: https://codereview.chromium.org/1561233003 .
|
Fix for lambdas: https://codereview.chromium.org/1579303002/ Funny to chase down the bug, only to see a TODO(jmesserly) describing the problem :) |
R=leafp@google.com Review URL: https://codereview.chromium.org/1579303002 .
jmesserly
added
Priority-Medium
and removed
P1
|
dropping priority, as the only cases left are the instantiated tear-offs & functions. |
|
There's an interesting instantiated tear off example at dart-archive/dev_compiler#426. It uses a generic function as a default argument. For that example, we'd also have to allow function instantiations to be treated as constant expressions. |
|
CL is out for downward inference on instantiations. So even if we don't have syntax support yet, at least they will work in an inferred context. See #25619 |
|
split out the remaining issues into a new bug: #25824, as they're lower priority than what this bug originally covered |
kevmoo
added
P2
Right now generic function calls are only supported for the MethodInvocation AST node, which applies to method calls like
o.m<t>(...)and function calls likef<t>(...)We need to support these:
o.mo.m<t>var y = f<int>;(f)(1, 2)or(f)<int>(1, 2)<T>(T x) => xThe text was updated successfully, but these errors were encountered: