Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use FunctionTypedElement.type while generating method overrides #671

Closed
wants to merge 0 commits into from
Closed

Use FunctionTypedElement.type while generating method overrides #671

wants to merge 0 commits into from
+0 −0

Conversation

copybara-service[bot]
Copy link

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.

Fixes #658

@yanok yanok mentioned this pull request Jul 5, 2023
Closed
1 task
@copybara-service copybara-service bot closed this Jul 5, 2023
@copybara-service copybara-service bot deleted the test_545613608 branch July 5, 2023 15:29
copybara-service bot pushed a commit that referenced this pull request Jul 6, 2023
@copybara-github
First attempt was #671
e1a766b 
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:

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
@copybara-service copybara-service bot mentioned this pull request Jul 6, 2023
Closed
copybara-service bot pushed a commit that referenced this pull request Jul 7, 2023
@copybara-github
Second attempt to fix "not found" error for type vars in bounds
72e4f3c 
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
copybara-service bot pushed a commit that referenced this pull request Jul 11, 2023
@copybara-github
Second attempt to fix "not found" error for type vars in bounds
b6bd57e 
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
copybara-service bot pushed a commit that referenced this pull request Jul 11, 2023
@copybara-github
Second attempt to fix "not found" error for type vars in bounds
2d4817d 
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
copybara-service bot pushed a commit that referenced this pull request Jul 12, 2023
@copybara-github
Second attempt to fix "not found" error for type vars in bounds
ffbbb4c 
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: 547427000
mosuem pushed a commit to dart-lang/test that referenced this pull request Oct 17, 2024
@copybara-github
Second attempt to fix "not found" error for type vars in bounds
7ff4f58 
First attempt was dart-lang/mockito#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 dart-lang/mockito#658

PiperOrigin-RevId: 547427000
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
customer-google3
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Code generation error on nested generic bounded type arguments
0 participants