Definitively a type-checker failure. The new cycle detection code is overly aggressive.

Independent reproducer:

$ cat x.go
package p

const preloadLimit LNumber = 128

type LNumber float64

func (LNumber) assertFunction() *LFunction

type LFunction struct {
	GFunction LGFunction
}

type LGFunction func(*LState)

type LState struct {
	reg *registry
}

type registry struct {
	alloc *allocator
}

type allocator struct {
	_ [int(preloadLimit)]int
}

Running gotype in it yields:

$ gotype x.go 
x.go:3:7: illegal cycle in declaration of preloadLimit
x.go:3:7: 	preloadLimit refers to
x.go:5:6: 	LNumber refers to
x.go:7:16: 	assertFunction refers to
x.go:9:6: 	LFunction refers to
x.go:13:6: 	LGFunction refers to
x.go:15:6: 	LState refers to
x.go:19:6: 	registry refers to
x.go:23:6: 	allocator refers to
x.go:3:7: 	preloadLimit

This is awfully wrong. Will fix in the next few days.

A trivial fix is to set

const useCycleMarking = false

in go/types/decl.go:57. This will disable the new code and the bug disappears (but it will also undo some other fixes, and the test suite will need to disable some tests).

Shorter (go/types says C -> T -> M -> C):

package p
const C T = 1
type T int
func (T) M() [C]T

It seems to me that the "C -> T" link is spurious. For cycle detection it seems like a constant shouldn't care about its own type or initializer, so this should be cycle-free too:

package p
const C = T(1)
type T int
func (T) M() [C]T

But maybe I am missing some subtlety around constants. It's been a while.

Also the cycle via the method (assertFunction) is odd. I think it shouldn't be very hard to fix, probably tomorrow. Thanks for the shorter reproducer. (I kept the longer one so I have a test case for the original problem.)

@rsc I'm using elsewhere a slightly different algorithm that breaks this cycle after C->T. The difference is in that methods are typechecked separately, after non-methods.

Snippet of actual code

        cs := &cstack{p: p}
	for _, sf := range p.SourceFiles {
		for _, d := range sf.TopLevelDecls {
			if x, ok := d.(*MethodDecl); ok {
				cs.reset().check(x, nil)
			}
		}
	}
	for _, sf := range p.SourceFiles {
		for _, d := range sf.TopLevelDecls {
			if _, ok := d.(*MethodDecl); !ok {
				cs.reset().check(d, nil)
			}
		}
	}
	p.checkEnqueued(cs)
	for _, sf := range p.SourceFiles {
		for _, d := range sf.InitFunctions {
			d.(*FuncDecl).checkBody(cs)
		}
	}
	p.checkEnqueued(cs)
	for _, sf := range p.SourceFiles {
		for _, d := range sf.TopLevelDecls {
			switch x := d.(type) {
			case *FuncDecl:
				x.checkBody(cs)
			case *MethodDecl:
				x.checkBody(cs)
			}
		}
	}
	p.checkEnqueued(cs)

For cycle detection it seems like a constant shouldn't care about its own type or initializer,

I think that would not be correct.

@cznic Thanks for this. We can't completely change the algorithm at this point but I agree that methods should be handled separately. There's an independent/related issue open for that (#23203).

Change https://golang.org/cl/121755 mentions this issue: go/types: correctly compute cycle length

Change https://golang.org/cl/121757 mentions this issue: go/types: ignore artificial cycles introduced via method declarations

The CL https://go-review.googlesource.com/c/go/+/121757 fixes this issue. Running go/vet on the repo now produces:

$ go vet
# github.com/yuin/gopher-lua
./channellib.go:49: reflect.SelectCase composite literal uses unkeyed fields
./compile.go:1051: unreachable code
./compile.go:1052: unreachable code
./compile.go:1111: unreachable code
./state.go:1142: unreachable code
./utils.go:260: reflect.SliceHeader composite literal uses unkeyed fields
./vm.go:777: self-assignment of cf.ReturnBase to cf.ReturnBase
./vm.go:779: self-assignment of cf.NRet to cf.NRet
./vm.go:1229: unreachable code
./script_test.go:57: result of (*lua.FunctionProto).String call not used
./state_test.go:244: unreachable code
./state_test.go:262: unreachable code

all of which look correct to me.

Change https://golang.org/cl/139899 mentions this issue: go/types: remove work-around for issue #26124