Possible issue with go vet and/or gopls

[Arnaud Delobelle]

Hi all

I ran into this error with generic types.  Here is the sample program below, which is my best effort to boil it down to its simplest expression.

I can build and run the program fine with go 1.23.0.  However, on line 15 vscode reports the error I put in the comment on that line. I do not know how to determine what tool is instructing vscode to report this error (I imagine it's gopls but I have no proof).

package main

import "fmt"

func main() {

b := B{X: &A1{X: B{}}, Y: &A2{X: B{}}}

fmt.Printf("b = %#v", b)

}

type A1 struct {

X B

}

type A2 struct {

X B // invalid use of type alias B in recursive type (see go.dev/issue/50729)compilerInvalidDeclCycle

}

type G[T1, T2 any] struct {

X *T1

Y *T2

}

type B = G[A1, A2]

Here is the same program in the go playground: https://go.dev/play/p/fjy9259UHPY.  If I click "Run" I get this output:

# [play]
vet: ./prog.go:15:4: invalid use of type alias B in recursive type (see go.dev/issue/50729)

Go vet failed.

b = {X:0xc00009e050 Y:0xc00009e060}
Program exited.

So "go vet" fails, but the program builds and runs OK.  However, if I run "go vet" on my machine, no errors are reported!

Can someone explain what is happening? To sum up

- the program builds and runs even though an error is reported in vscode and the same error by go vet on the Go playground

- go vet reports an error in the Go playground, but not on my machine (they both reportedly run go 1.23.0)

- possibly gopls reports this error too?  I do not know if it is the tool that tells vscode of the error on my machine (I run gopls 0.16.1)

What I'd like to know:

- if someone can tell me how to determine what tool is telling vscode to report this error, it would help me find where to report this issue

- if someone could confirm whether the program is indeed supposed to be correct, it would also help me (I suspect it should be correct, as it builds and runs successfully)

Thanks in advance

-- 

Arnaud

PS: Apologies for the html-formatted email, but I couldn't figure out how to paste code into gmail without losing all the indentation

[peterGo]

Arnaud,

$ go version && go run alias.go && go vet alias.go
go version devel go1.24-96d8ff00c2 Sat Aug 24 00:51:40 2024 +0000 linux/amd64
b = {X:0xc00011c190 Y:0xc00011c1a0}
$

Or

$ go1.23 version && go1.23 run alias.go && GODEBUG=gotypesalias=1 go1.23 vet alias.go
go version go1.23.0 linux/amd64
b = {X:0xc0000141c0 Y:0xc0000141d0}
$

peter

[Arnaud Delobelle]

Hi Peter,

Thanks for mentioning gotypesalias.  Looking into that, I see that the go1.23 release notes mention that:

    By default, go/types now produces Alias type nodes for type aliases. This behavior can be controlled by the GODEBUG gotypesalias flag. Its default has changed from 0 in Go 1.22 to 1 in Go 1.23.

This is supported by the test below.  By default go vet does not flag the error, but it does if GODEBUG=gotypesalias=0 (so GODEBUG=gotypesalias=1 was redundant in your command)

❯ go version

go version go1.23.0 darwin/arm64
echo $GODEBUG

❯ go vet sample.go
❯ GODEBUG=gotypesalias=0 go vet sample.go
# command-line-arguments
# [command-line-arguments]
vet: ./sample.go:15:4: invalid use of type alias B in recursive type (see go.dev/issue/50729)

However on the Go playground go vet reports the error (https://go.dev/play/p/fjy9259UHPY).  Does this mean that the Go playground is configured with GODEBUG=gotypesalias=0? Is that not an issue with the Go playground?  I think the Go playground should give output consistent with a local installation.

Also it seems that gopls flags this error too by default, even though go vet no longer does.  This also appears to me to be an issue, though a lot harder to diagnose because I can only observe the outcome via the black box of vscode (or another editor configured with gopls).  I do not know how to run gopls as a standalone tool on a file (I do not even know if such a thing is possible).

-- 

Arnaud

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3084309c-bac4-4851-ab1f-364568b4400cn%40googlegroups.com.

[peterGo]

Arnaud,

My local devel example version,

go version devel go1.24-96d8ff00c2 Sat Aug 24 00:51:40 2024 +0000

Your Go Playground devel example version,run at at 2024-08-25 23:38:42.008121446 +0000 UTC, is earlier,

devel go1.24-b6f05cc333 Tue Aug 20 13:39:19 2024 +0000

peter

[peterGo]

Arnaud,

GODEBUG=gotypesalias=1 was not redundant in my command. It was used to suppress go vet error checking.

peter

[Arnaud Delobelle]

On Mon, 26 Aug 2024 at 01:27, peterGo <go.pe...@gmail.com> wrote:

Arnaud,

GODEBUG=gotypesalias=1 was not redundant in my command. It was used to suppress go vet error checking.

As I understand it from the go 1.23 release notes (confirmed by the test below), it doesn't suppress anything - it's the reverse: GODEBUG=gotypesalias=0 which enables it as in go1.23 the default value is 1.  So it was redundant in the sense that it doesn't change the output of go vet.  So it still is unexplained to me why the Go playground outputs the go vet error.

❯ go version
go version go1.23.0 darwin/arm64

❯ GODEBUG='' go vet sample.go
❯ GODEBUG=gotypesalias=1 go vet sample.go

❯ GODEBUG=gotypesalias=0 go vet sample.go
# command-line-arguments
# [command-line-arguments]

vet: ./sample.go:15:4: invalid use of type alias B in recursive type (see go.dev/issue/50729)

-- 

Arnaud

 

peter

 

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ef0fd15b-27ed-433f-a519-122ff3e84974n%40googlegroups.com.

[Arnaud Delobelle]

On Mon, 26 Aug 2024 at 00:58, peterGo <go.pe...@gmail.com> wrote:

Arnaud,

My local devel example version,

go version devel go1.24-96d8ff00c2 Sat Aug 24 00:51:40 2024 +0000

Your Go Playground devel example version,run at at 2024-08-25 23:38:42.008121446 +0000 UTC, is earlier,

devel go1.24-b6f05cc333 Tue Aug 20 13:39:19 2024 +0000

I selected "Go 1.23" the Go playground version and ran my example code with go1.23, so AFAICT go1.24 is not relevant to what I'm trying to understand.  For go1.23 it's the same version running in the Go playground and locally (1.23.0) so I expect go vet to have the same output.

-- 

Arnaud

 

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/70329ab2-726c-43dc-a124-0e00c6b52ab8n%40googlegroups.com.