Second attempt to fix "not found" error for type vars in bounds #673
+0
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Second attempt to fix "not found" error for type vars in bounds
First attempt was #671
and I had to roll it back, since it caused breakages in two ways:
ParameterElement
fromtype.parameters
hadenclosingElement
set to
null
and we use that in one helper function. That was easy tofix, we could just pass
methodElement
to that function directly.It's probably correct that
ParameterElement
of aFunctionType
doesn't link back to a
MethodElement
, but it's weird that sometimesit 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 (totallycorrect, 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
andparameters
for the rest asbefore.
Original commit description:
Use
FunctionTypedElement.type
while generating method overridesTurns out
FunctionTypedElement.typeParameters
could be inconsistentfor
MethodMember
s returned byInheritanceManager3.getMember2
.FunctionTypedElement.type.typeFormals
seem to be always good, butwe have to also use
type.parameters
andtype.returnType
insteadof just
parameters
andreturnType
in this case.Fixes #658