go/types: API changes to support explicit Alias nodes

[griesemer]

Background

Currently, when a type alias declaration

type A = some_type

is type-checked, go/types creates a TypeName Object for the type alias A but the type of the TypeName is the type of some_type. When A is used as identifier in source code, the denoted type is some_type, which if it's a defined type will have a different name than A; and if it's not a defined type, it will be a type literal, which is also not called A. As a consequence, an error message related to the type A will not report A but some_type or whatever type A is a alias for. This is a long-standing issue that we'd like to fix.

Furthermore, with proposal #46477 accepted (parameterized type aliases), currently go/types doesn't have a way to represent a parameterized alias type.

Both these problems can be addressed with an explicit Alias type node. This proposal is about introducing such a new type node.

Proposal

We introduce a new go/types node called Alias:

// An Alias represents an alias type.
type Alias struct {
	obj     *TypeName // corresponding declared alias object
	fromRHS Type      // RHS of type alias declaration; may be an alias
	actual  Type      // actual (aliased) type; never an alias

	// additional fields for type parameters
}

// Obj returns the type name for the declaration defining the alias a.
func (a *Alias) Obj() *TypeName { return a.obj }

// Methods supported by all types
func (*Alias) Underlying() Type
func (*Alias) String() string 

An Alias node stands for a type alias. An Alias node is created with a factory function:

func NewAlias(obj *TypeName, rhs Type) *Alias

When an Alias node is encountered, go/types and related tool clients may need to indirect to the actual type the Alias node is a type alias for. This can be done through a new function

// Unalias returns t if it is not an alias type;
// otherwise it follows t's alias chain until it
// reaches a non-alias type which is then returned.
// Consequently, the result is never an alias type.
func Unalias(t Type) Type

Tools that care about the actual un-aliased type will need to call Unalias everywhere in the tools code where there is a type assertion or type switch and the type may be an alias type.

This is a non-backward compatible change to go/types and it may require pervasive changes to tools, with a potentially long bug tail. For that reason we also propose to introduce a new types.Config flag:

// If EnableAlias is set, alias declarations produce an Alias type.
// Otherwise the alias information is only in the type name, which
// points directly to the actual (aliased) type.
EnableAlias bool

Unless EnableAlias is set, go/types behaves exactly as before. If EnableAlias is set, Alias nodes appear for type alias declarations, and clients of go/types will need to be aware of that.

Discussion

This proposal only introduces the Alias node functionality, without support for type parameters. We believe this is a significant change which should be done separately from support for parameterized alias types, ideally for Go 1.22. Once the new API is settled and clients have adjusted, we would then extend the Alias node with support for type parameters and instantiation, presumably for Go 1.23. As that step doesn't introduce a new type node, we expect it to be easier to adjust clients.

Unfortunately we don't see a way around introducing an explicit Alias node if we want to support parameterization, and therefore we don't see a way to support parameterized alias types in a backward-compatible way. The EnableAlias configuration flag should help ease the transition: tools will continue to work as before if this proposal is accepted. Only when they set the configuration flag will they need to be aware of the new type node.

Implementation

An initial implementation can be found here: CL 521956 with unexported API changes.
The compiler doesn't set EnableAlias yet. Also, changes to the compiler (calls to Unalias) and exporters/importers are missing.

[griesemer]

cc: @findleyr @ianlancetaylor @mdempsky

[mvdan]

I would love this for tools - I have struggled with not being able to distinguish aliases before. The approach with the option sounds good to me.

Is _Alias a typo in the godoc? Not sure what the underscore is for.

[griesemer]

@mvdan The CL implements this proposal but the proposal needs to be discussed and accepted first. Once we're confident that the CL is ready we may submit it, with the API changes unexported (with a leading _). We plan to adjust (as needed) and export once the proposal is accepted.

[mvdan]

To be clear, I only mean in this issue body - the type is declared as Alias, but referred to as _Alias in a godoc.

[griesemer]

@mvdan I fixed one typo. Not sure if there's others.

[findleyr]

This proposal looks good, and I'm excited for the simplifications this will enable in gopls.

I have some questions about the details:

• In NewAlias, should we pass in the RHS, or the actual type? For NewNamed, we pass in the underlying and panic if the underlying is a Named type. Should we do the same for Alias, accepting an actual type, and panicking if actual is an alias? This matters for import/export: we have no way to access the RHS type and therefore couldn't preserve it in export data.
• provocative speculation: Could we have -lang=go1.23 imply EnableAlias, and avoid supporting the mode where we only produce alias nodes if they are generic? Any tools supporting 1.23 will have to deal with Alias anyway, and it avoids the strange partial representation. Unfortunately, I don't think we can avoid the EnableAlias flag entirely because we can't break tools that currently work find for older Go versions.

[mvdan]

I have struggled with not being able to distinguish aliases before.

If you want more specifics, and fancy getting horrified by my workaround, see: https://github.com/burrowers/garble/blob/82834ace20257dcbb4a9bc9493cce6d69418f4b7/main.go#L1383-L1389

That entire chunk of code could be replaced by this new option and Alias type, as far as I can tell!

[findleyr]

Oh, are we sharing workarounds :)? This entire function could probably be replaced by types.TypeString, if go/types handles aliases: https://cs.opensource.google/go/x/tools/+/master:gopls/internal/lsp/source/types_format.go;l=270;drc=5fc00b44cd9b4227deece2f4611a2e3d4ce47475

[timothy-king]

Should there also be a helper function that combines Unalias() and Underlying() until a non-named type is reached? My guess is most [but not all] uses of Underlying() will need to be replaced by this helper. (Similar to the CoreType replacements in x/tools.) We can always delay introducing this to go/types seeing if this is indeed the case.

[mdempsky]

Alternative idea: what if Object.Type() and Type.Underlying() continue to behave the same as today, but we add a method Alias() *Alias to the Type interface, which points back to the Alias that the type was originally accessed through, if any.

So like type A = *int would create a TypeName for A, whose Type() would be a copy of the type.Pointer that represents *int, but calling Alias() on it would return the Alias representing A. (Caveat: for GODEBUG below, we would define that it may instead return nil if alias information isn't available.)

Then existing alias-unaware code continues working the same, while alias-aware code can always find the Alias type when it wants it, even if the Type value came from alias-unaware code.

The only tricky thing would be aliases to Basic and Named. I know within the Go compiler (types1), we assume that defined types always have a unique type instance, so that we can do direct pointer comparisons on them (though we special case any, byte, and rune). I don't see it formally documented in the go/types APIs, so users shouldn't be relying on it, but that doesn't mean they aren't. (Actually, go/types special cases byte and rune basically the same way, by giving them a separate Basic instance.)

So potentially some go/types code would break if we duplicate Basic and Named types so they can store the Alias pointer. We could offer a GODEBUG knob to disable this behavior though. That would allow the problematic alias-unaware code to continue working, while alias-aware code would gracefully degrade to work without Alias information for Named and/or Basic and/or everything.