-
Notifications
You must be signed in to change notification settings - Fork 18k
types2: adjust types reported for shift expressions with constant RHS to match go/types
#47410
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
Comments
Change https://golang.org/cl/337529 mentions this issue: |
CL 291316 fixed go/types to verify that untyped shift counts are representable by uint, but as a side effect also converted their types to uint. Rearrange the logic to keep the check for representability, but not actually convert untyped integer constants. Untyped non-integer constants are still converted, to preserve the behavior of 1.16. This behavior for non-integer types is a bug, filed as #47410. Updates #47410 Fixes #47243 Change-Id: I5eab4aab35b97f932fccdee2d4a18623ee2ccad5 Reviewed-on: https://go-review.googlesource.com/c/go/+/337529 Trust: Robert Findley <rfindley@google.com> Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Findley <rfindley@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Change https://golang.org/cl/338195 mentions this issue: |
@griesemer This is in the 1.18 milestone; time to move to 1.19? Thanks. |
There's a pending CL with failures. It's on my list to investigate. |
The issue here is what type is reported through the API but in contrast to |
go/types
Change https://go.dev/cl/396775 mentions this issue: |
CL 337529 introduced upfront type-checking of constant shift operands, to avoid converting their type to uint (per the spec). However, it had an oversight in that the checks intended for non-constant operands still ran after the explicit checking of constant operands. As a result, there are at least two bugs: - When GoVersion is < 1.13, we report spurious errors for untyped constant shift operands. - When the operand is an untyped float constant, we still convert to uint (this was a known bug reported in #47410). Looking at this now, it seems clear that we can avoid both of these bugs by simply not running the additional checks in the case of a constant operand. However, this should be considered with some care, as shifts are notoriously tricky. Updates #47410 Fixes #52031 Change-Id: Ia489cc5470b92a8187d3de0423d05b309daf47bb Reviewed-on: https://go-review.googlesource.com/c/go/+/396775 Reviewed-by: Robert Griesemer <gri@golang.org> Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Change https://go.dev/cl/397680 mentions this issue: |
… shifts on Go < 1.13 CL 337529 introduced upfront type-checking of constant shift operands, to avoid converting their type to uint (per the spec). However, it had an oversight in that the checks intended for non-constant operands still ran after the explicit checking of constant operands. As a result, there are at least two bugs: - When GoVersion is < 1.13, we report spurious errors for untyped constant shift operands. - When the operand is an untyped float constant, we still convert to uint (this was a known bug reported in #47410). Looking at this now, it seems clear that we can avoid both of these bugs by simply not running the additional checks in the case of a constant operand. However, this should be considered with some care, as shifts are notoriously tricky. While cherry-picking, the new test file is updated to use the go1_12 package name, following our convention for specifying language version in the release branch. Fixes #52032 Change-Id: Ia489cc5470b92a8187d3de0423d05b309daf47bb Reviewed-on: https://go-review.googlesource.com/c/go/+/396775 Reviewed-by: Robert Griesemer <gri@golang.org> Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit 8a816d5) Reviewed-on: https://go-review.googlesource.com/c/go/+/397680
Moving to 1.20. Should make the adjustment for use with the unified IR. |
This doesn't affect users of Go. It's just a consistency issue between type2 and go/types. Easier to fix once we only have the unified IR. Moving to 1.21. |
Too late for 1.21. |
Moving to 1.23. |
Moving to 1.24. |
It appears that this has been fixed (probably through a combination of the CLs mentioned in this issue). The playground example reports:
i.e., the recorded types of Closing and considered fixed. |
As discussed in #47243, go/types should preserve the type of untyped constants on the RHS of a shift expression.
However, it does this inconsistently for integral vs non-integral types. Consider
In 1.16 (and probably earlier), go/types reports the type of
1
asuntyped int
, but the type of2.
asuint
. It should preserve the type of2.
asuntyped float
.https://play.golang.org/p/aZZ48onPW2z
We're going to preserve this behavior for 1.17, but should try to fix it for 1.18.
CC @griesemer
The text was updated successfully, but these errors were encountered: