Evaluate enum constants with go/constant

[paskal]

Previously the generator recognised only iota, a plain literal, and a binary expression combining iota with one of +, -, * or /. Every other constant expression silently became zero, because the evaluator returned an error that was then discarded in favour of a zero value. That covered shifts, bitwise operators, parentheses, references to other constants, and every literal that is not plain decimal, since the literal converter scanned with %d and stopped at the first character it did not recognise. An enum written as

const (
    permRead perm = 1 << iota
    permWrite
    permExecute
)

generated value: 0 for all three constants, and 0x10, 0b1010 and 1_000 became zero in the same way. With -getter the duplicate zeroes failed generation instead.

On one source file, the same constants before and after:

constant	expression	before	after
permRead, permWrite, permExec	1 << iota	0, 0, 0	1, 2, 4
permAll	^perm(0)	0	255
permBase	base, declared as 0x10	0	16
permCalc	perm(base/2 + len("ab"))	0	10
permNeg	1_0 - 2	-1	8

The -1 in the last row was written into a uint8 field, so that file did not compile at all. Every value in the last column is the one the compiler computes for the same constant, checked by generating the enum and comparing Index() against the original constant in a test.

After this change constant expressions are evaluated with go/constant. The whole integer operator set is supported, together with literals in any base, conversions, len, min, max, and references to other constants declared in the package. The type a constant carries is followed through the expression, since it decides several results: ^perm(0) complements within the width of perm, a typed integer divides as an integer, and a constant declared float32 holds its value at the width of that type. Values are kept exact rather than narrowed to int, so a uint64 enum above MaxInt64 keeps its value. A constant declared without an expression repeats the expression of the preceding one, which is the rule the language itself applies, instead of replaying a recorded operation. Each of these cases was checked against the value the compiler computes for the same constant, in a differential comparison over 38 expressions and by generating enums and comparing Index() against the original constant.

Values that cannot be evaluated, and values that do not fit the underlying type of the enum, are now reported as errors rather than becoming zero. Two things are deliberately left out and named in the error: a constant of another package, which would need the type checker and a resolvable import graph, and the constant built-ins other than len, which do not appear in enum declarations. The complement of int, uint and uintptr is refused as well, since its value depends on the width of the target architecture while the generated file holds one number.

What changes for existing users:

• An enum built on an unsupported expression generated wrong values before and generates correct ones now. Index() and Get...ByID change accordingly, so a project that persisted those integers needs to consider a migration.
• Generation now fails, instead of writing a file, when a constant cannot be evaluated, for instance when it refers to a constant of another package, and when its value overflows the underlying type of the enum.
• The generated API is unchanged.