cmd/compile: export format of untyped constants is unnecessarily restricted

[griesemer]

The compiler exports untyped constants' format to their respective type. types2 and go/types together with the go/constant package don't require a constant representation to match the (untyped) constant type. For instance, it's ok to represent real(0) of type untyped float with a constant of kind constant.Int.

Should remove this restriction from the export format as it may cause loss of precision and also lead to larger than necessary export data. This will require an extra byte for each exported constant, encoding the respective constant kind. This will also require a bump of the export data version.

Marking for go1.18 since we are changing the export format anyway (generics). But it's not crucial to get this in.

See #43891 for details.

[mdempsky]

Does go/types only ever use more precise representations, or can it use more relaxed representations too? E.g., can an untyped integer/rune constant be represented by a constant.Float, or an untyped float represented by a constant.Complex?

The export data format should also be extended to support rational constants, so they don't need to be truncated to floating point. (We've discussed this before, but I don't see any open issues about it.)

[griesemer]

I don't think that the representation can be more relaxed. Untyped constants's kind usually matches the constant kind but when we apply a type (e.g. an untyped 1 is really a float64 1.0) in context we don't necessarily change the constant representation, leading to a 1.0 that is represented as an constant.Int 1.

Agreed on the rational constants.

[gopherbot]

Change https://golang.org/cl/358035 mentions this issue: go/internal/gcimporter: stub support importing/exporting constant kind

[griesemer]

Moving the final fix to 1.19. This has worked so far and will keep working.