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

cmd/compile: incorrect type set intersection computation [1.19 backport] #57499

Closed
gopherbot opened this issue Dec 28, 2022 · 4 comments
Closed
Labels
CherryPickCandidate Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Milestone

Comments

@gopherbot
Copy link
Contributor

@griesemer requested issue #57486 to be considered for backport to the next 1.19 minor release.

This is now fixed (but not yet submitted). As @ianlancetaylor correctly noted, this should not have worked with Go 1.18 or Go 1.19.

@gopherbot please consider this for backport to 1.18 and 1.19. This is a compiler bug.

@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Dec 28, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Dec 28, 2022
@gopherbot gopherbot added this to the Go1.19.5 milestone Dec 28, 2022
@dmitshur dmitshur changed the title cmd/compile: incorrectly allow to use a type parameter as type argument (not very sure it is a bug or not) [1.19 backport] cmd/compile: incorrect type set intersection computation [1.19 backport] Dec 28, 2022
@gopherbot
Copy link
Contributor Author

Change https://go.dev/cl/460016 mentions this issue: [release-branch.go1.19] go/types, types2: use strict comparability for type set intersection

@heschi
Copy link
Contributor

heschi commented Jan 4, 2023

This seems like a low-severity problem, and last time we backported a fix like this, for sync.Atomic, it caused some collateral damage. Is there a compelling case to not just wait for 1.20 in a few weeks?

@griesemer
Copy link
Contributor

The primary reason for backporting would be for people who cannot (or don't want to) move to 1.20. People using 1.18 and and 1.19 can write code that the compiler accepts but that is in fact incorrect (though I don't have a simple example where such incorrectly compiled code can be used to exploit something - it'll take some ingenuity to find such an example).

The actual fix in the type checker is extremely straight-forward - most of the rest of the CL is simply for the test cases. I'm not worried too much about collateral damage.

My take: if there's no more point release for 1.18 and 1.19, then let's not do this. If there are point releases for other reasons, then let's include this fix.

@gopherbot gopherbot modified the milestones: Go1.19.5, Go1.19.6 Jan 10, 2023
@heschi
Copy link
Contributor

heschi commented Jan 18, 2023

We have a track record of all kinds of trouble with generics changes, even very innocuous-looking ones. This is a low-severity issue, and we're trying to be more conservative, so we decided to decline this one. Sorry.

@heschi heschi closed this as not planned Won't fix, can't repro, duplicate, stale Jan 18, 2023
@golang golang locked and limited conversation to collaborators Jan 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
CherryPickCandidate Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Projects
None yet
Development

No branches or pull requests

3 participants