go/types: string(1 << s) should be an error

[griesemer]

package main

func main() {
	var s uint
	_ = string(1 << s)
}

(https://play.golang.org/p/owHsmdZd32v) is an error: The 1 in 1 << s assumes the type it would have without the shift, which is string. Both cm/compile and gccgo correct report an error.

go/types appears to accept it.

[griesemer]

In this case (string(number)) where the string conversion is not simply changing the type of the argument but actively changing its value and representation, it would make sense for the shift rules to not look at the context. Or turning it around, maybe this kind of conversion should not be permitted in the first place, as proposed via #3939.

[griesemer]

On Wed, Jun 27, 2018 at 4:20 PM Tim Cooper ***@***.***> wrote: Related #21981 <#21981>?

Indeed. Thanks! - gri

…

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#26096 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIIkTz1DNDGIP360-WywgYHcVHHXxWrjks5uBBMzgaJpZM4U6bt6> .

[griesemer]

Also related: #21982

[griesemer]

On (go/types) conversions.go:61 we select untyped int (the current type of 1 in string(1 << s)) as type for 1 (i.e., we don't change it). If we don't do anything special in this case (integer to string conversions), the type of 1 will become srtring and we get the expected error message.

Unfortunately, doing nothing there causes regular conversions (such as string('a')) to break because the argument to the conversion is not compatible with string anymore.

Fixing this requires a bit more subtle changes. Postponing for now since this is a) unlikely to occur in real programs, b) there are easy work-arounds, and c) this doesn't prevent go/types from accepting legal programs.

The issue may also become moot if we remove string(int/rune) conversions (#3939).