It does look incomplete. Fortunately, it doesn't matter too much from a correctness perspective. From the beginning of cmd/compile/internal/gc/type.go:

// convenience constants
const (
	Txxx = types.Txxx

	TINT8    = types.TINT8
	TUINT8   = types.TUINT8
	TINT16   = types.TINT16
	TUINT16  = types.TUINT16
	TINT32   = types.TINT32
	TUINT32  = types.TUINT32
	TINT64   = types.TINT64
	TUINT64  = types.TUINT64
	TINT     = types.TINT
	TUINT    = types.TUINT
	TUINTPTR = types.TUINTPTR

	TCOMPLEX64  = types.TCOMPLEX64
	TCOMPLEX128 = types.TCOMPLEX128

	TFLOAT32 = types.TFLOAT32
	TFLOAT64 = types.TFLOAT64

Indeed - I can't even see the difference anymore... . The factoring is in progress, so feel free to clean up as you see fit.

Thanks. To be sure: "clean up" means switch to the types. constants when possible (for example, always when writing new code); and the long term goal is to delete the dups @josharian pointed out exist in gc?

I started switching to the types constants but everything became incredibly verbose. So for now I'd say use the local constants. The factoring as it is clearly doesn't improve the code, but it makes it more explicit what kind of dependencies exist. Ideally (long run) we'd like to use a more direct representation of each type (one struct per type, rather than a Type struct with extension), and make Type an interface (which is already used in some form by the ssa backend).

Thanks for the explanation.

I'm going to close this issue since a) I fixed the specific inconsistency in truncfltlit in another CL b) it's now clear that the goal of your CL was not to switch everything to the types. constants.