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

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

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Aug 29, 2018

@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.

@griesemer
Copy link
Contributor

@griesemer griesemer commented Sep 5, 2018

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 ]

Loading

@griesemer
Copy link
Contributor

@griesemer griesemer commented Sep 5, 2018

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).

Loading

@andybons
Copy link
Member

@andybons andybons commented Sep 11, 2018

@ianlancetaylor what do you think?

Loading

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Sep 12, 2018

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.

Loading

@andybons
Copy link
Member

@andybons andybons commented Sep 13, 2018

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

Loading

@andybons andybons closed this Sep 13, 2018
@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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants