Skip to content

cmd/compile: cannot convert v (variable of type *Bar[T]) to type *Foo[T] [1.18 backport] #52558

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
Closed
gopherbot opened this issue Apr 25, 2022 · 2 comments
Closed

cmd/compile: cannot convert v (variable of type *Bar[T]) to type *Foo[T] [1.18 backport] #52558

gopherbot opened this issue Apr 25, 2022 · 2 comments
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Milestone
Go1.18.2

Comments

@gopherbot
Copy link
Contributor

@findleyr requested issue #52529 to be considered for backport to the next 1.18 minor release.

@gopherbot, please open a backport issue for 1.18, this is a bug causing valid code not to compile.
@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Apr 25, 2022
@gopherbot gopherbot mentioned this issue Apr 25, 2022
Closed
@gopherbot gopherbot added this to the Go1.18.2 milestone Apr 25, 2022
@gopherbot
Copy link
Contributor Author

Change https://go.dev/cl/403754 mentions this issue: [release-branch.go1.18] go/types,types2: delay the check for conflicting struct field names

@dr2chase dr2chase added the CherryPickApproved Used during the release process for point releases label May 4, 2022
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label May 4, 2022
@gopherbot
Copy link
Contributor Author

Closed by merging f4f1999 to release-branch.go1.18.

gopherbot pushed a commit that referenced this issue May 9, 2022
@findleyr @heschi
[release-branch.go1.18] go/types,types2: delay the check for conflict…
f4f1999 
…ing struct field names

In #52529, we observed that checking types for duplicate fields and
methods during method collection can result in incorrect early expansion
of the base type. Fix this by delaying the check for duplicate fields.
Notably, we can't delay the check for duplicate methods as we must
preserve the invariant that added method names are unique.

After this change, it may be possible in the presence of errors to have
a type-checked type containing a method name that conflicts with a field
name. With the previous logic conflicting methods would have been
skipped. This is a change in behavior, but only for invalid code.
Preserving the existing behavior would likely require delaying method
collection, which could have more significant consequences.

As a result of this change, the compiler test fixedbugs/issue28268.go
started passing with types2, being previously marked as broken. The fix
was not actually related to the duplicate method error, but rather the
fact that we stopped reporting redundant errors on the calls to x.b()
and x.E(), because they are now (valid!) methods.

Updates #52529
Fixes #52558

Change-Id: I850ce85c6ba76d79544f46bfd3deb8538d8c7d00
Reviewed-on: https://go-review.googlesource.com/c/go/+/403455
Reviewed-by: Robert Griesemer <[email protected]>
Run-TryBot: Robert Findley <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
(cherry picked from commit b75e492)
Reviewed-on: https://go-review.googlesource.com/c/go/+/403754
@golang golang locked and limited conversation to collaborators May 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Projects
None yet
Milestone
Go1.18.2
Development

No branches or pull requests
2 participants
@dr2chase @gopherbot