Somewhat related: #21982.

If the left operand of a constant shift expression is an untyped constant, the result is an integer constant;

This suggests in the code below that 'a' << 1 should be an integer constant, so x should be given the default type int, and the blank assignment should succeed.

var x = 'a' << 1
var _ int = x

However, cmd/compile and go/types both give x the type rune, so the assignment is rejected.

doesn't integer constants include rune constants?

I also think 'x' is an integer constant. It's just its default type is rune.

rune is an alias for int32, which is defined as an integer type. But there doesn't appear to be any wording to suggest that "rune constants" are a subclass of "integer constants."

I think that 'x' is not (yet) a rune constant, but an untyped integer constant. In certain contexts, like in foo := 'x' it becomes a rune. In string('x') its default type (rune) is IMO not relevant. I think that it's in the later case actually (due to context) first converted to int, not rune, like in the (IMHO) equivalent string(120).

I think that 'x' is not (yet) a rune constant, but an untyped integer constant.

That's not what the Go spec says (emphasis added):

A rune literal represents a rune constant, an integer value identifying a Unicode code point.

Rune constants are integer values, but not integer constants.

I agree with @mdempsky that there is at least some imprecision if not inconsistency in the spec in this area. We use mildly similar terminology for different purposes (integer value vs integer constant vs integer vs int type, etc.) and these terms are vaguely defined if at all.

I think we need to clearly define these terms in one place (consistent with existing use) and then this issue (and related ones) should become clear.