The go/doc package doesn't contain any information about type aliases. For aliases to types defined in external packages there is not much to be done, but an alias to a type in the same package can define methods on either name for the type and those should either be consolidated or appropriately replicated.

Currently go/doc works entirely off the ast with no type info but I believe this should be sufficient for deriving local type aliases.

I propose two additional fields on doc.Type:

  AliasFor *Type
  Aliases []*Type

AliasFor is only non-nil if the current type is an alias for another type in the current package. It is nil if the given type is an alias to an identifier not found in the current package.

Aliases is only non-nil if the current type is not an alias but other types in the current package are an alias for it.

These should take transitivity into account, so that type A = B, type B = C, type C struct{} would result in C listing both A and B as Aliases. Likewise the AliasFor field on both A and B would point to C. This allows C to easily be discovered as the "canonical" definition of the type.

It would make it easy to copy the methods defined on various aliases to all appropriate types and to do things like "if a local alias has no doc string, use the doc from the 'original' type" or to display a single entry with all the aliases listed. If the "canonical" definition of the type is unexported but one or more of its aliases are exported, the unexported names could be hidden and all the public information of the type copied to one of its exported names.

An initial version could choose not to export these fields and only use this information internally to copy methods, allowing the decision of how to expose this information to be postponed.

If later go/doc allows the option to use type info instead of heuristics #22918 it could grab the relevant information from that type info instead of having to compute it itself.