x/tools/gopls: gopls suggests to import maps from internal/runtime/maps

[xieyuschen]

gopls version

Build gop with x/tools tip 8d1f71aa2

golang.org/x/tools/gopls v0.35.1-0.20250714143223-8d1f71aa2c54

go env

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='0'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/xieyuschen/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/xieyuschen/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build4029252794=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/xieyuschen/codespace/tools/go.mod'
GOMODCACHE='/home/xieyuschen/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/xieyuschen/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/xieyuschen/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.2'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

I have a package, along with a cmd package under project root, the module name is github.com/xieyuschen/ibkr-go.

.
├── LICENSE
├── README.md
├── cmd
│   └── generate.go
├── go.mod

I typed maps.

What did you see happen?

Gopls suggests maps import from internal/runtime/maps.

Gopls doesn't report an error for usage var _ maps.Iter as well:

When running go command, go will complain:

package github.com/xieyuschen/ibkr-go/cmd
        cmd/generate.go:7:2: use of internal package internal/runtime/maps not allowed

Currently, gopls only reports an error at the import place:

What did you expect to see?

It's reasonable for gopls to avoid offering package internal/runtime/maps suggestion when typed maps.

I would like to track it and send the fix, if you think it's a reasonable change. Please let me know if I have missed some background here.

Editor and settings

No response

Logs

No response

[gabyhelp]

Related Issues

• x/tools/gopls: gopls completes a function from an unimported module in the vendor path but uses an incorrect import path with "vendor/" #71474
• x/tools/internal/imports: import embed in files containing go:embed directives #50414
• x/tools/gopls: unable to find package #38271 (closed)
• x/tools/gopls: could not import xxxx (no package for import xxxx) #42828 (closed)
• x/tools/gopls: organizeImports does not find package after changing its name #67973
• x/tools/gopls: allow disabling "invalid use of internal package" analysis #66856 (closed)
• x/tools/gopls: workspaces ignore vendor directory when not go-getable #52587
• x/tools/gopls: when working in vendor mode autoimport adds packages from `vendor` dir #56291 (closed)
• x/tools/gopls: "could not import ___" after adding new _test package #36635 (closed)
• x/tools/gopls: source.organizeImports offers filepath instead of package path #46630 (closed)

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

[h9jiang]

I think this is reasonable to implement, defer to @adonovan for final decision.

[adonovan]

I agree, this is a definite bug: organizeImports should not suggest imports that cannot be imported. At least when using the Go build system, it should be trivial to detect /internal/ packages. (Indeed, I thought gopls already did so.)