Tip regression, thanks for reporting it.

cc @danscales @griesemer

In 1.17 and prior (and also -G=0 mode in 1.18), you get a wrong error:

test.go:5:16: invalid operation: 1 << n (shift of type string)

This seems to be a bug with the OLSH/ORSH case in typecheck.convLit1. As far as I can tell, the code is legal (both untyped values 1 and 6 should be interpreted as ints).

I will work on the crash in the compiler. Despite the crash, this is probably not a release blocker (as noted by @ALTree ), since the case was already marked as illegal code in 1.17 and prior.

Actually "invalid operation: 1 << n (shift of type string)" is the correct error. See the discussion of shift expressions at https://go.dev/ref/spec#Operators.

Getting an internal compiler error rather than a proper error is indeed a regression, though I agree that it is not a critical one.

OK, thanks for clarifying! Sounds like this is a types2 typechecker bug then. I will assign to @griesemer for now.

BTW, I actually did look at the spec. This rule:

The right operand in a shift expression must have integer type or be an untyped constant representable by a value of type uint. If the left operand of a non-constant shift expression is an untyped constant, it is first implicitly converted to the type it would assume if the shift expression were replaced by its left operand alone.

did not immediately make me think that an explicit outer string() conversion can actually control the assumed type of the left operand. But I do see that there is an example in the spec using uint64(1 << s) in the spec, so I guess the string case should be parallel. Will definitely be good to add a test case for this example.

It seems to me that the test is $GOROOT/test/shift1.go, in the line

	v float32 = 1 << s   // ERROR "invalid"

We could certainly add a similar line with string replacing float32 if it makes a difference.

For some reason, the types2 typecheck flags this case as an error:

        var n = 6
        var x string = 1 << n // ERROR "invalid"

but not the example in this bug (and then the compiler gives the internal compiler error):

       var n = 6
       var + = string(1 << n) // ERROR "invalid"

Also, if you replace string with float32, the types2 typechecker catches both cases. So, we do need to include this new example in the shift1.go file.

Actually "invalid operation: 1 << n (shift of type string)" is the correct error. See the discussion of shift expressions at https://go.dev/ref/spec#Operators.

While the error is technically correct, it is still confusing. A better error would be nice.

Duplicate of #45117.