Sometimes ParameterElement from type.parameters had enclosingElement
set to null and we use that in one helper function. That was easy to
fix, we could just pass methodElement to that function directly.
It's probably correct that ParameterElement of a FunctionType
doesn't link back to a MethodElement, but it's weird that sometimes
it does, so it wasn't caught in the tests. I had to get rid of
using type.parameters anyway because of the second problem.
type.parameters don't contain parameters' default values (totally
correct, since default values belong to methods, not to types), but
that means we can't use them, since we do need default values.
So I ended up with a more hacky solution, that uses type.typeFormals
just to get correct references for method's type parameters, and then
uses typeParameters, returnType and parameters for the rest as
before.
Original commit description:
Use FunctionTypedElement.type while generating method overrides
Turns out FunctionTypedElement.typeParameters could be inconsistent
for MethodMembers returned by InheritanceManager3.getMember2.
FunctionTypedElement.type.typeFormals seem to be always good, but
we have to also use type.parameters and type.returnType instead
of just parameters and returnType in this case.
Second attempt to fix "not found" error for type vars in bounds
First attempt was https://github.com/dart-lang/mockito/pull/671 and I had to roll it back, since it caused breakages in two ways:
ParameterElement
fromtype.parameters
hadenclosingElement
set tonull
and we use that in one helper function. That was easy to fix, we could just passmethodElement
to that function directly. It's probably correct thatParameterElement
of aFunctionType
doesn't link back to aMethodElement
, but it's weird that sometimes it does, so it wasn't caught in the tests. I had to get rid of usingtype.parameters
anyway because of the second problem.type.parameters
don't contain parameters' default values (totally correct, since default values belong to methods, not to types), but that means we can't use them, since we do need default values.So I ended up with a more hacky solution, that uses
type.typeFormals
just to get correct references for method's type parameters, and then usestypeParameters
,returnType
andparameters
for the rest as before.Original commit description:
Use
FunctionTypedElement.type
while generating method overridesTurns out
FunctionTypedElement.typeParameters
could be inconsistent forMethodMember
s returned byInheritanceManager3.getMember2
.FunctionTypedElement.type.typeFormals
seem to be always good, but we have to also usetype.parameters
andtype.returnType
instead of justparameters
andreturnType
in this case.Fixes #658