gopls can not work in project with go mod go 1.22

[nanozuki]

Describe the bug

Gopls not work with go_1_22 in a go 1.22 go project.

Steps To Reproduce

Steps to reproduce the behavior:

1. Install go_1_22 and gopls in home-manager
2. Create a go hello world project: mkdir hello && cd hello && go mod init "hello"

   package main
   
   import "fmt"
   
   func main() {
    fmt.Println("Hello, World!")
   }

3. Use editor neovim open this file, navigate to function Println, call GoToDefination. Nothing happened.
4. If I modified the go.mod file, change go version to go 1.21, the editor can navigate to the definition.

Expected behavior

At step 3, the editor can go to built-in definition for fmt.Println.

Additional context

If needed, I can create a repo use flake.nix to reproduce these situation, or any other things to help to solve this.

Some other report: #290212 (comment)

Notify maintainers

@zowoq @kirillrdy

Metadata

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"aarch64-darwin"`
 - host os: `Darwin 23.3.0, macOS 14.3.1`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.18.1`
 - nixpkgs: `/nix/store/fpr5fsl88azrdsbzjpfq2hk307bbr7cm-source`

---

Add a 👍 reaction to issues you find important.

[kirillrdy]

using https://github.com/sumnerevans/nixpkgs-290212 looks like if gopls is built with go_1_22, it works on projects with go.mod 1.21

so easiest fix is to just bump buildGoModule for gopls ang golangci-lint .
I would prefer to avoid adding something like go_latest and buildGoLatestModule, but maybe there is no better way

or we could namespace tools under go itself

eg go.gopls, and go_1_21.gopls, but then not sure how users will know about those, and toplevel gopls will still exists and still needs to be updated to point to "latest"

[kirillrdy]

thoughts @SuperSandro2000 ? ( as gopls maintainer )

EDIT, for some reason i though you were sole maintainer, but then i realised i confused gopls with golangci-lint-langserver

[katexochen]

so easiest fix is to just bump buildGoModule for gopls ang golangci-lint .
I would prefer to avoid adding something like go_latest and buildGoLatestModule, but maybe there is no better way

I still don't think this is the right approach. Packages that currently don't work with Go 1.22.0 won't work with 1.22.1 either. Upstream must implement the support for the next minor version, so the constraint in toolchain is closely related to the package itself. That's why the package that depends on an older version of Go should explicitly pin that toolchain so that we can just use the latest Go release by default.

This will also save us work in the long term, as we wouldn't introduce a new group of Go packages that need special treatment (be it with buildGoLatestModule or setting latest manual). Packages will still need to pin 1.21 if we update default later.

[kirillrdy]

I still don't think this is the right approach. Packages that currently don't work with Go 1.22.0 won't work with 1.22.1 either. Upstream must implement the support for the next minor version, so the constraint in toolchain is closely related to the package itself. That's why the package that depends on an older version of Go should explicitly pin that toolchain so that we can just use the latest Go release by default.

I am a bit confused by this comment.

I still don't think this is the right approach

i said, its simplest

Packages that currently don't work with Go 1.22.0 won't work with 1.22.1 either

gopls ( package in question ) works with 1.22.0, should also work with 1.22.1

That's why the package that depends on an older version of Go should explicitly pin that toolchain

nixpkgs pins go for any package that is not compatible with default version

I think, most likely there is just some miscommunication going on, so please treat my comments as such

[kirillrdy]

after reading your comment again, i think you suggestion is instead of pinning gopls and friends ( eg golangci-lint)
you suggesting is to change default and ping everything that is not compatible ?

is this right ? ( sorry for replying before you )

[SuperSandro2000]

Packages that depend on older go versions are usually not good maintained or need an update.

Lots of the go development tools need to be built with the latest version they should support. If we add a new alias that always points to the latest version, then we can probably forget to update the pinnings for those packages. Bumping the default go version is not always that easy and usually generates a bit of fallout and it is usually better to do that a bit delayed.

[kirillrdy]

i think @SuperSandro2000 sums it up pretty well, I was just hoping to avoid adding new alias

[katexochen]

after reading your comment again, i think you suggestion is instead of pinning gopls and friends ( eg golangci-lint) you suggesting is to change default and ping everything that is not compatible ?

is this right ? ( sorry for replying before you )

Yes, that is my suggestion.

Bumping the default go version is not always that easy and usually generates a bit of fallout

I understand this, but I think this is rather an issue on our side we should fix and not a problem intrinsic to the Go toolchain.

[kirillrdy]

given #293629

should we just bump buildGoModule for gopls ang golangci-lint ? as quick fix, while we think about how to resolve it more permanently ?

[budimanjojo]

I can confirm that using buildGo122Module instead fixed my problem. And it also works fine on project with go 1.21.
Was debugging this for hours before finding this issue.