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
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).
Reviewed-by: Alan Donovan <email@example.com>
"If the left operand of a non-constant shift expression is an untyped constant, it is first converted to the type it would assume if the shift expression were replaced by its left operand alone."
If we replace the shift expression, we get 1 + 1.0, which cannot be converted to string. Ergo, we can't convert the original expression to string either.
Also, we do allow shifting of untyped float constants (e.g., int(1.0 << s)), so I think the proposed error message (cannot shift 1 (untyped float value)) would be misleading. And the same expression is valid in some other contexts (e.g., int(1<<s + 1.0)), so I think mentioning the string conversion aspect is important.