Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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: 1. 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. 2. `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 `MethodMember`s 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. Fixes #658 PiperOrigin-RevId: 545934516
- Loading branch information