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.

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

go/types: assertion failure setting up composite literal with incomplete element type [1.11 backport] #27351

Closed
gopherbot opened this issue Aug 29, 2018 · 5 comments
Closed

go/types: assertion failure setting up composite literal with incomplete element type [1.11 backport] #27351

gopherbot opened this issue Aug 29, 2018 · 5 comments
Labels
CherryPickCandidate Used during the release process for point releases FrozenDueToAge
Milestone
Go1.11.1

Comments

@gopherbot
Copy link

@FiloSottile requested issue #27346 to be considered for backport to the next 1.11 minor release.

@gopherbot please file this for backport against 1.11. This is a regression.
@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Aug 29, 2018
@gopherbot gopherbot mentioned this issue Aug 29, 2018
Closed
@gopherbot gopherbot added this to the Go1.11.1 milestone Aug 29, 2018
@griesemer
Copy link
Contributor

griesemer commented Sep 5, 2018 •
edited

This was fixed in the master branch via the following two submits:

https://golang.org/cl/132235 [ please note the correct CL is below ]
https://golang.org/cl/132355 [ actual fix ]
https://golang.org/cl/133415 [ comment update and extra tests ]

@griesemer
Copy link
Contributor

This issue is not a regression (was always present) and only occurs when the code is invalid in the first place. It is not clear to me that it needs to be cherry-picked. On the other hand, the fix is extremely safe and simple (the first CL contains the fix, which is trivial, the 2nd CL contains extra tests and better comments only).

@andybons
Copy link
Member

@ianlancetaylor what do you think?

@ianlancetaylor
Copy link
Contributor

I haven't looked at the patch, but I think we definitely do not need to backport a fix to a problem that is not a regression and that only arises on invalid code. Our default decision should always be to not backport. We should only consider backporting changes that fix serious problems with no workaround. Anything involving invalid code is by definition not serious, and by definition has a workaround.

@andybons
Copy link
Member

Closing. I think Ian's wording should be more prominent on our backporting policy page. Will add that.

@golang golang locked and limited conversation to collaborators Sep 13, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
CherryPickCandidate Used during the release process for point releases FrozenDueToAge
Projects
None yet
Milestone
Go1.11.1
Development

No branches or pull requests
4 participants
@andybons @ianlancetaylor @griesemer @gopherbot