go/types: wrong line numbers in errors for constant overflows involving iota

[griesemer]

go test -run Check$ -files $GOROOT/test/fixedbugs/issue8183.go --errlist

produces

    check_test.go:267: .../issue8183.go:12:12: cannot convert iota + 253 (untyped int constant 256) to byte
    check_test.go:267: .../issue8183.go:19:11: invalid array length 1 - iota (untyped int constant -1)
    check_test.go:267: .../issue8183.go:19:11: invalid array length 1 - iota (untyped int constant -2)

yet the correct line numbers are 15, 21, and 22.

[griesemer]

go/types doesn't make a copy of the syntax trees for "copied" constant expressions in grouped constant declarations; it evaluates them with the correct iota value but at their original position. As a result we get the wrong line numbers in the result. I'm amazed this has not come up in the last few years of go/types use.

One possibility might be to remember a line correction delta when we evaluate an expression containing an iota. The line correction delta is the iota value.

Follow-up: @findleyr I think I've got a fairly simple fix for this. Need to rethink/test/clean up etc. but hopefully should be ready sometime tomorrow or over the weekend.

[findleyr]

Thanks for investigating this @griesemer. I'm not sure I understand your point about using the iota value to compute correction delta, since there need not be any correlation between iota value and line number, for example https://play.golang.org/p/FQfRsDMMv8v.

[griesemer]

@findleyr Yes, you're correct - I've realized that last night as well. Turns out we just need to remember the position of the actual constant being initialized; in fact we need that position anyway to be able to position the error correctly. In short: Whenever we evaluate a constant initialization expression that is "inherited" from (shared with) other constants, we remember the position of the constant identifier. If there's an error in the initialization expression, we use the position of the constant identifier (this is stored in the current Checker context) for the error location (and we can still point to the original expression as well).

[gopherbot]

Change https://golang.org/cl/275517 mentions this issue: [dev.typeparams] cmd/compile/internal/types2: correct error position for inherited const init expression

[gopherbot]

Change https://golang.org/cl/276172 mentions this issue: go/types: correct error position for inherited const init expressions