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: valid string(1<<s) is not accepted #21981

griesemer opened this issue Sep 22, 2017 · 3 comments


None yet
3 participants
Copy link

commented Sep 22, 2017


tmp/sandbox014611473/main.go:5:12: invalid operation: 1 << s (shift of type string)

which is clearly wrong. The program should compile and run.

@griesemer griesemer added the NeedsFix label Sep 22, 2017

@griesemer griesemer added this to the Go1.10 milestone Sep 22, 2017


This comment has been minimized.

Copy link

commented Sep 22, 2017

Change mentions this issue: go/types: don't accept incorrect shift expression arguments

gopherbot pushed a commit that referenced this issue Sep 25, 2017

go/types: don't accept incorrect shift expression arguments
Under certain circumstances involving shifts, go/types didn't verify
that untyped constant values were representable by the relevant type,
leading to the acceptance of incorrect programs (see the issue).

Fixing this code exposed another problem with int-to-string conversions
which suddenly failed because now the type-checker complained that a
(constant) integer argument wasn't representable as a string. Fixed that
as well.

Added many additional tests covering the various scenarious.

Found two cmd/compile bugs in the process (#21979, #21981) and filed
a go/types TODO (#21982).

Fixes #21727.

Change-Id: If443ee0230979cd7d45d2fc669e623648caa70da
Reviewed-by: Alan Donovan <>

This comment has been minimized.

Copy link

commented Sep 27, 2017

It's not obvious to me that the error is wrong. If complex128(1<<s) is invalid, why should string(1<<s) be valid?

I realize integer-to-string conversion is a different kind of conversion than integer-to-complex, but I can't immediately spot any spec wording that suggests this distinction is relevant here.

@griesemer griesemer modified the milestones: Go1.10, Go1.11 Nov 29, 2017

@griesemer griesemer self-assigned this Nov 29, 2017

@griesemer griesemer modified the milestones: Go1.11, Go1.12 Jun 27, 2018


This comment has been minimized.

Copy link
Contributor Author

commented Jun 27, 2018

This is indeed not an error; in fact go/types is wrong. See #26096.

@griesemer griesemer closed this Jun 27, 2018

@griesemer griesemer removed the NeedsFix label Jun 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.