cmd/compile: make alias decls work correctly under all circumstances

[griesemer]

[edit: This is now the umbrella issue for work on alias declarations. This includes parameterized alias declarations; see issue #46477. It also includes proper names for aliases in error messages.]

The original fix for #18640 was only partially correct. However, removing that incorrect code leads to another cycle related issue for the test case:

type (
	e = f
	f = g
	g = []h
	h i
	i = j
	j = e
)

Left the original, partially correct code in place for now as it's not wrong, it just doesn't cover the expected cases and it appears to circumvent this issue.

Marking for 1.11 if we get to it but it's not a showstopper.

Commented out this test case in test/fixedbugs/issue18640.go for now.

[gopherbot]

Change https://golang.org/cl/118078 mentions this issue: cmd/compile: correct alias cycle detection

[griesemer]

Simpler reproducer:

type (
	e = []h
	h e
)

Yet, the equivalent code (after substituting e with []h) is accepted as expected:

type h []h

[griesemer]

(Slightly) simpler reproducer:

package pkg
type P = *T
type T P

The code is accepted if the order of the type declarations is swapped. The bug is likely in type-checking alias declarations that refer to defined types that have not yet been set up and which refer back to the alias type. We end up with an incorrect type T T and dowith goes belly up.

[griesemer]

This bug (and the related bugs) are due to an incorrect implementation of type aliases in the presence of cycles. The bug(s) can be made to disappear by re-ordering the code (though it may not be obvious, and it may not always be possible). Furthermore, the actual underlying problem was hidden by a typo in the cycle-detection code which left the code "surprisingly correct". Here's this first problem:

In function typecheck (typecheck.go), when we detect a typechecking look (n.Typecheck() == 2), in the case of n.Op == OTYPE where we are expecting a type, we check if the loop contains any (non-alias) type definition. If so, the cycle is permitted (for now, it may still be invalid when we compute the type size). However, if we find a non-alias type definition, instead of returning the incoming node, we return the node we found in the loop (because the loop iteration variable is also named n)! Thus we continue with the wrong type which happens to be a defined type node that has a TFORW type attached to it and then much of the rest "works" w/o blowing up, albeit incorrectly. In some cases a cyclic type of defined types is created which then results in a cycle error during type size computation in the dowith function. Once we fix this, in code with alias cycles, the type-checker will simply crash.

To correctly fix this in all situations we (very likely) have to bite the bullet and introduce a TALIAS type which is simply a forwarder to the actual type, very similar to the existing TFORW, except that we won't be able to simply update the TALIAS type to the underlying type since in general we cannot have two versions of the (underlying) type - they must be the same type (pointer). To make this work, we must ensure that all accesses to a Type always forward to the aliased type if the type is a TALIAS.

So the fix is about as follows:

1. Introduce a new Etype TALIAS, update the Type data structure as needed.
2. Fix the "first" problem mentioned above.
3. When type-checking an alias declaration, introduce a TALIAS type which serves as the anchor when we run into a cycle.
4. Make sure that we always indirect through TALIAS types if we encounter them.

Much of 4) can be achieved my accessing Type information only via accessors and the accessors take care of the forwarding. Alternatively (and perhaps more efficiently), the accessors verify that we never access a TALIAS (which they already do by virtue of checking the Etype is correct), and making sure we resolve TALIAS types before calling accessors.

[gopherbot]

Change https://golang.org/cl/147286 mentions this issue: cmd/compile: reintroduce work-around for cyclic alias declarations

[mdempsky]

Introducing TALIAS sounds like a reasonable solution, and doing so probably even makes sense to address #21866. I expect this to be non-trivial though.

For brainstorming though, I think another option for addressing cycles would be to break package-scope declaration typechecking into a few more phases:

1. For each declared type, create a TFORW placeholder.
2. For each declared type, typecheck the underlying type. Unlike today, however, we would only recursively typecheck alias types (not other declared types); we'd also defer calculating array lengths (so we don't need to calculate sizes or typecheck variable types, or anything else tricky involved in constant folding).
3. Re-enable constant evaluations, and typecheck remaining package-scope declarations (variables, functions, constants, and type aliases).

By only recursively typechecking aliases during step 2, we guarantee if we get into a loop, then it's because of an invalid alias loop.

And by deferring calculating array lengths, we have no need for calculating widths, so the TFORW placeholders are fine to use without eagerly recursively typechecking them. (I think this would amount to my suggestion on #13890.)

[gopherbot]

Change https://golang.org/cl/147597 mentions this issue: go/types: avoid certain problems with recursive alias type declarations (referenced wrong issue number in CL).

[griesemer]

I have removed the ReleaseBlocker label here. The primarily visible problem (incorrect cycle reported via dowith) has been fixed with https://golang.org/cl/147286 and people have been living ok with the remaining alias cycle issue. We clearly still need to fix this in full but if we don't get it done for 1.12 it will be ok. Fixing it may require more changes than we are willing to accept at this point of the freeze, and there may be higher priority work having a bigger impact.

[gopherbot]

Change https://golang.org/cl/151339 mentions this issue: [release-branch.go1.11] cmd/compile: reintroduce work-around for cyclic alias declarations

[griesemer]

Too late in cycle to do more work here. Moving to 1.13.

[griesemer]

With #46477 accepted, we will need to review handling of aliases during type checking, so moving this to 1.19.

[vellotis]

For awareness, I just ran into this bug in 1.17.

[gopherbot]

Change https://golang.org/cl/380056 mentions this issue: cmd/compile/internal/types2: reorder object processing to avoid broken aliases

[gopherbot]

This issue is currently labeled as early-in-cycle for Go 1.19.
That time is now, so a friendly reminder to look at it again.

[griesemer]

Moving this to 1.20. The 1.19 cycle is very short and we don't have a concrete plan for this yet.

[gqcn]

I just ran into this issue internal compiler error: cannot handle alias type declaration (issue #25838): HandlerFunc

[griesemer]

@gqcn You may be able to work around the issue with some clever reordering of the code. In any case, sadly we won't have the bandwidth to handle this before 1.20, I think.

[gopherbot]

This issue is currently labeled as early-in-cycle for Go 1.20.
That time is now, so a friendly reminder to look at it again.

[griesemer]

We're unlikely to get to this in this cycle. Moving forward again.

[gopherbot]

This issue is currently labeled as early-in-cycle for Go 1.21.
That time is now, so a friendly reminder to look at it again.

[gopherbot]

This issue is currently labeled as early-in-cycle for Go 1.22.
That time is now, so a friendly reminder to look at it again.

[gopherbot]

Change https://go.dev/cl/521956 mentions this issue: go/types, types2: introduce _Alias type node

[griesemer]

We now have support for Alias nodes which can be enabled with GODEBUG=gotypesalias=1 which addresses these issues.
Closing this in favor of more fine-grained issues related to outstanding alias problems when Alias nodes are enabled.