gopls version

Build info

golang.org/x/tools/gopls v0.18.1 golang.org/x/tools/gopls@v0.18.1 h1:2xJBNzdImS5u/kV/ZzqDLSvlBSeZX+pWY9uKVP7Pask= github.com/BurntSushi/toml@v1.4.1-0.20240526193622-a339e1f7089c h1:pxW6RcqyfI9/kWtOwnv/G+AzdKuy2ZrqINhenH4HyNs= github.com/google/go-cmp@v0.6.0 h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI= golang.org/x/exp/typeparams@v0.0.0-20241210194714-1829a127f884 h1:1xaZTydL5Gsg78QharTwKfA9FY9CZ1VQj6D/AZEvHR0= golang.org/x/mod@v0.23.0 h1:Zb7khfcRGKk+kqfxFaP5tZqCnDZMjC5VtUBs87Hr6QM= golang.org/x/sync@v0.11.0 h1:GGz8+XQP4FvTTrjZPzNKTMFtSXH80RAzG+5ghFPgK9w= golang.org/x/telemetry@v0.0.0-20241220003058-cc96b6e0d3d9 h1:L2k9GUV2TpQKVRGMjN94qfUMgUwOFimSQ6gipyJIjKw= golang.org/x/text@v0.22.0 h1:bofq7m3/HAFvbF51jz3Q9wLg3jkvSPuiZu/pD1XwgtM= golang.org/x/tools@v0.30.1-0.20250221230316-5055f70f240c h1:Ja/5gV5a9Vvho3p2NC/T2TtxhHjrWS/2DvCKMvA0a+Y= golang.org/x/vuln@v1.1.3 h1:NPGnvPOTgnjBc9HTaUx+nj+EaUYxl5SJOWqaDYGaFYw= honnef.co/go/tools@v0.5.1 h1:4bH5o3b5ZULQ4UrBmP+63W9r7qIkqJClEA9ko5YKx+I= mvdan.cc/gofumpt@v0.7.0 h1:bg91ttqXmi9y2xawvkuMXyvAA/1ZGJqYAEGjXuP0JXU= mvdan.cc/xurls/v2@v2.5.0 h1:lyBNOm8Wo71UknhUs4QTFUNNMyxy2JEIaKKo0RWOh+8= go: go1.24.2

go env

AR='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE='on'
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/fabianr/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/fabianr/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/81/cvjd0t010fgbf1nc2p9xcq4w0000gn/T/go-build3394958907=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/fabianr/svn/be/trunk/gamelogic/gohome/src/elk/go.mod'
GOMODCACHE='/Users/fabianr/svn/be/trunk/gamelogic/gohome/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/fabianr/svn/be/trunk/gamelogic/gohome'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/fabianr/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.24.4'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

Ran gopls definition on the variable names of the snippet

type (
    Named  int
    Alias  = Named
    Alias2 = Alias
)

var (
    named  Named
    alias  Alias
    alias2 Alias2
)

What did you see happen?

I got the definitions var named Named, type Named int and var alias2 Alias2, respectively.

What did you expect to see?

I would expect the definition of the alias variable to be of, well, a variable; probably var alias Alias. Interestingly enough the second-degree alias isn't affected.

Editor and settings

No response

Logs

No response

Comment From: gabyhelp

Related Issues

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Comment From: adonovan

This behavior was implemented by https://go.dev/cl/644495. I think there are three problems here:

1) hovering over (a def or use of) alias now reports a type, not a var. This is categorically a regression. 2) hovering over alias shows its RHS type (int) whereas hovering over alias2 shows its surface type (Alias2). This inconsistency is a bug. It could be fixed two ways (always or never unalias, and if unaliasing, do so recursively). 3) was https://github.com/golang/go/issues/71286 (unalias) a mistake? I am inclined to think so. If you hover over a reference to alias far from its declaration, it's useful to know its alias type name. You can also execute a definition query then hover again if you want to strip the alias this type off.

So I vote for reverting CL 644495 and restoring the old behavior. Thoughts?

Comment From: xieyuschen

  1. Hovering over alias but showing type Named int is a surprising bug, I can fix it if you don't have any other concern.
  2. This is intended as comment here said as I agreed with @findleyr 's comment here. If the inconsistency causes confusion so it becomes a bug, I prefer to show the surface type for variable rather than unalias it.
  3. It's a nice feature but the implementation has some problems, and I would like to fix them.

Comment From: adonovan

  1. Hovering over alias but showing type Named int is a surprising bug, I can fix it if you don't have any other concern.

Thanks, much appreciated.

  1. This is intended as comment here said as I agreed with @findleyr 's comment here. If the inconsistency causes confusion so it becomes a bug, I prefer to show the surface type for variable rather than unalias it.

Yeah, I think we collectively didn't see all the details here. I agree with you that it would be simpler and more consistent to show the surface type for the variable in all cases, since even alias types carry useful information. The user can always dig deeper with further clicks, but there's no way to restore the information lost due to overly eager unwrapping.

  1. It's a nice feature but the implementation has some problems, and I would like to fix them.

I agree that it is useful to additionally present the unaliased type information, but we need to be consistent. Thanks again for offering to improve it.

Comment From: gopherbot

Change https://go.dev/cl/685775 mentions this issue: gopls/internal/golang/hover: show alias real type decl for types only