Gopls settings -> buildFlags

Language Server Protocol (LSP)
1

When working on *.go files with build tags defined, I get undeclared name errors. It appears as thought I can specify gopls settings using the below structure, but the problem remains which makes me believe they aren’t being applied properly.

nvim_lsp.gopls.setup{
  on_attach = on_attach,
  capabilities = capabilities,
  filetypes = { "go", "gomod" },
  root_dir = util.root_pattern("go.mod", ".git"),
  settings = {
    gopls = {
      buildFlags =  {"-tags=integration"},
    }
  },
}

I have the following directory, where I’ve been able to reproduce the problem:

.
├── go.mod
└── internal
    └── stringhelpers
        ├── strings_main_test.go
        └── strings_test.go

// strings_main_test.go

// +build integration

package stringhelpers_test

import "testing"

func TestMain(m *testing.M) {
	m.Run()
}

func getString() string {
	return "test-"
}

// strings_test.go

// +build integration

package stringhelpers_test

import (
	"strings"
	"testing"
)

func TestHasPrefix(t *testing.T) {
	if strings.HasPrefix("test-123", getString()) != true {
		t.Fail()
	}
}

When editing internal/stringhelpers/strings_test.go, I see the following error:

image
image805×663 27.8 KB

When I remove the build tags, the problem goes away.

Is there a way to capture whether the buildFlag is being set properly?

2

Other options do work (e.g. usePlaceholders) (Note: I’ve since changed to a default_config method, the buildFlags still do not work):

configs.gopls = {
  default_config = {
    cmd = {'gopls', '--remote=auto'},
    filetypes = { "go", "gomod" },
    settings = {
      gopls = {
        usePlaceholders = true,
        buildFlags =  {"-tags=integration"},
        gofumpt = true,
      }
    },
  }
}

Also note, you cannot specify the gopls local setting; presumably because it’s a reserved word in lua.

configs.gopls = {
  default_config = {
    cmd = {'gopls', '--remote=auto'},
    filetypes = { "go", "gomod" },
    settings = {
      gopls = {
        local = "repo"
      }
    },
  }
}
3

I can’t answer your question re: buildFlags (seems like a gopls issue for which I’d search around on their issue tracker to make sure you are sending the right flag), but, re: your local question, you can add protected keywords to a lua table by quoting them and surrounding in brackets:

:lua print(vim.inspect({["local"] = true}))

4

Thanks for the reply!

seems like a gopls issue for which I’d search around on their issue tracker to make sure you are sending the right flag

I’m not convinced it is a gopls issue. I had the exact same configuration set-up when I was using coc, which worked fine.

re: your local question, you can add protected keywords to a lua table by quoting them and surrounding in brackets

ah. Excellent. Thanks!

5

I’m pretty sure coc is sending the same things you are placing in settings in init_options, these are different things (settings is sent via workspaceDidChangeConfiguration, init_options is sent during server startup)

6

Does that mean, to replicate the same behaviour I had in coc, I would do something like this?

configs.gopls = {
  default_config = {
    cmd = {'gopls', '--remote=auto'},
    filetypes = { "go", "gomod" },
    settings = {
      gopls = {
        usePlaceholders = false,
        buildFlags =  {"-tags=integration"},
        gofumpt = true,
        ["local"] = "repo",
      }
    },
    init_options = {
      buildFlags =  {"-tags=integration"},
    }
  }
}

I’ve tried both this, and with a nested gopls object in-between init_options and buildFlags to no avail.

I assume there’s something small I’m missing :thinking:

7

Hmm I’m actually getting the same issue in vscode as in your OP

image
image1228×804 57.8 KB

image
image984×194 18.1 KB

So I’ll try to reproduce with coc later and see if they are sending something that vscode/lspconfig is not.

8

Weirdly the example I posted in the OP still has the issue but, through trying all the different things, my main repo that I was trying to fix now doesn’t have the problem…

So it looks like maybe it’s a code problem now :thinking: :man_shrugging:

9

I also just tested with coc, same error as vscode/the built-in lsc

image
image1710×552 42.9 KB

10

I think I figured it out, it’s actually an environmental variable for gopls. See (Build Tag support · Issue #56 · josa42/coc-go · GitHub)

require('lspconfig').gopls.setup {
    cmd_env = {GOFLAGS="-tags=integration"}
}

You may have at one point set a default flags options in your coc.json? Not sure.

11

Sorry for the delay, @mjlbach. I have been doing some more testing and I don’t believe this is an issue with gopls, or vim-lsp; but more one of PEBKAC.

With the below set-up, I now cannot replicate the problem I described in the OP:

nvim_lsp.gopls.setup {
  on_attach = on_attach,
  capabilities = capabilities,
  filetypes = { "go", "gomod" },
  root_dir = util.root_pattern("go.mod", ".git"),
  settings = {
    gopls = {
      usePlaceholders = false,
      buildFlags =  {"-tags=integration"},
      gofumpt = true,
      ["local"] = "<repo>",
    }
  },
  init_options = {
    buildFlags =  {"-tags=integration"},
  }
}

While trying to figure out what was going on, every now and again I was seeing gopls requires a module at the root of your workspace errors; but it was rare and would go away again pretty quickly so thought it was part of gopls starting up or something.

This got me thinking and I decided to move away from the default_config method, which loops over the servers (seen here) as I wasn’t convinced the default root_dir was overwriting the root_dir I had defined in that loop (below)

local servers = { "tsserver", "vim_language_server" }
for _, lsp in ipairs(servers) do
  nvim_lsp[lsp].setup {
    on_attach = on_attach,
    capabilities = capabilities,
    root_dir = function(fname)
      return nvim_lsp.util.find_git_ancestor(fname) or vim.loop.os_homedir()
    end;
    flags = {
      debounce_did_change_notify = 250,
    };
  }
end

Once I did that, everything started working; so I believe it was an issue with how I was defining the root_dir function.

FWIW, I don’t believe the buildFlags is required in the init_options block; I’m just going to keep it (commented out) until I’m 100% satisfied everything works without it.

Appreciate all your time.