Typed iota value changes depending on declaration order

[dennwc]

The following program sample.go triggers an unexpected result

package main

const (
	A = Enum(iota)
	B
	C
)

type Enum int

func main() {
	println(A, B, C)
}

// Output:
// 0 1 2

Expected result

$ go run ./sample.go
// 0 1 2

Got

$ yaegi ./sample.go
// 0 2 4

Yaegi Version

f5b5481

Additional Notes

Moving type Enum int before const fixes the issue.

[dennwc]

I'm using this case currently to check the difference:

package main

const (
	A1 = Enum1(iota)
	A2
	A3
)

type Enum1 int

type Enum2 int

const (
	B1 = Enum2(iota)
	B2
	B3
)

func main() {
	println(A1, A2, A3)
	println(B1, B2, B3)
}

Expected output:

0 1 2
0 1 2

Actual output:

0 2 4
0 1 2

The Enum2 is correctly handled by gta, nothing interesting there. The type is registered upfront, so constant can be computed immediately.

However for Enum1 case it fails to compute the constant, thus pushing it to revisit list. Later is hits both CFG iota increment and GTA iota increment.

Actually, completely removing this GTA iota reset/increment code passes all the tests including the new one, so I'm wondering if it's needed there at all 🤔

yaegi/interp/gta.go

Lines 103 to 107 in f5b5481

	if childPos(n) == len(n.anc.child)-1 {
	sc.iota = 0
	} else {
	sc.iota++
	}

@mvertes any thoughts on this?

For now I'm not sure how to prevent the second increment from running, since constant value is assigned after both CFG and GTA increments run.

Maybe we could track the last node that caused the increment in the scope? Dropping GTA increment sounds dangerous, even though the tests are good.