cmd/compile: const decl with missing RHS interpreted subtly differently with 1.18

[zigo101]

The current spec says:

Within a parenthesized const declaration list the expression list may be omitted from any but the first ConstSpec. Such an empty list is equivalent to the textual substitution of the first preceding non-empty expression list and its type if any. Omitting the list of expressions is therefore equivalent to repeating the previous list.

By the explanation, the following two declarations are equivalent but are not actually (assume they are in local blocks):

const (
    A = iota
    iota = iota
    B
    C
)

const (
    A = iota
    iota = iota
    B = iota
    C
  )

It would be better to change "textual" into "lexical".

[ianlancetaylor]

CC @griesemer

[griesemer]

Nice pathological case!

[robpike]

I am missing what the pathology is, and why s/textual/lexical/ makes a difference. Please fill me in.

[griesemer]

In the first example, simply repeating the last present RHS where it is omitted leads to a different result (than leaving the RHS away) because the iota on the RHS of B = iota (after manually filling it in) is the user-defined, not the built-in iota. This effect is only possible for local constant declarations; at the package level we get a cycle error due to the different scope rules at the package level (see the example for all four cases).

Agreed that I don't know how using "lexical" would make this clearer. But stating that"Such an empty list is equivalent to the textual substitution of the first preceding non-empty expression list and its type if any." seems not quite correct.

[robpike]

I just wrote,

"I still don't see the problem. You're created a new variable called iota, so of course it's different."

and in writing that saw the problem. Wow, nice corner case.

[zigo101]

In fact, this is not an iota specific issue:

package main

const X = 3

func main() {
	const (
		X = X + X
		Y
	)
	
	println(X, Y)
}

[griesemer]

Looking at this again, it turns out that in Go 1.18 (with the new type checker) we actually get exactly the result as prescribed by the spec. For this example:

package main

const X = 3

func main() {
	const (
		X = X + X
		Y
	)
	println(X, Y)
}

Running with Go 1.18 we get the result 6 and 12, which corresponds exactly to using textually X + X for Y as the spec prescribes.

Running with 1.17 we get the result 6 and 6, corresponding to a copy of the syntax tree for X + X with the variables X resolved to the outer `X.

We have two possibilities:

1. The spec is wrong and we have a regression in 1.18.
2. The spec is correct and 1.18 fixed a long-existing bug.

There is a backward-compatibility issue here but this is a pathological situation that is unlikely to occur in correct code in the wild, and since 1.18 is out we have not heard any complaints about this.

Thus I am inclined to go 2) and close this issue.

@ianlancetaylor @robpike @rsc for feedback.