ray-x / go.nvim

G'day Nvimer, Joyful Gopher: Discover the Feature-Rich Go Plugin for Neovim
MIT License
1.9k stars 119 forks source link

[null-ls] failed to run generator: ...go/null_ls.lua:201: attempt to index field 'golangci_lint' (a nil value) #462

Closed rami3l closed 1 month ago

rami3l commented 1 month ago

Thanks a lot for making this plugin!

Recently I have encountered the above error when using this config derived from the project README's null-ls section:

  {
    "nvimtools/none-ls.nvim",
    opts = function(_, opts)
      if not opts.sources then opts.sources = {} end
      local go_nls = require("go.null_ls")
      opts.sources = vim.list_extend(opts.sources, {
        go_nls.golangci_lint(),
      })
      return opts
    end,
  },

Looking at the golangci_lint() function being called:

https://github.com/ray-x/go.nvim/blob/e80846dec565dac6418334cfc4eecc087678ff69/lua/go/null_ls.lua#L174-L175

... and particularly L201:

https://github.com/ray-x/go.nvim/blob/e80846dec565dac6418334cfc4eecc087678ff69/lua/go/null_ls.lua#L201-L207

... it looks like _GO_NVIM_CFG.null_ls exists, but not _GO_NVIM_CFG.null_ls.golangci_lint (so this will generate a nil), and _GO_NVIM_CFG.null_ls.golangci_lint.disable will cause an index error (same for L204). The current code has failed to handle this case.

:lua = _GO_NVIM_CFG ```lua { build_tags = "", comment_placeholder = "  ", dap_debug = true, dap_debug_gui = {}, dap_debug_keymap = true, dap_debug_vt = {}, dap_port = 38697, dap_retries = 20, dap_timeout = 15, diagnostic = {}, disable_defaults = false, disable_per_project_cfg = false, fillstruct = "gopls", floaterm = {}, go = "go", go_boilplater_url = "https://github.com/thockin/go-build-template.git", go_input = , go_select = , gocoverage_sign = "█", gocoverage_skip_covered = false, gofmt = "gopls", goimports = "gopls", gopls_remote_auto = true, gotests_template = "", gotests_template_dir = "", icons = {}, iferr_vertical_shift = 4, log_path = "/Users/rami3l/tmp/gonvim.log", lsp_cfg = false, lsp_codelens = true, lsp_diag_update_in_insert = false, lsp_document_formatting = true, lsp_fmt_async = false, lsp_gofumpt = false, lsp_inlay_hints = {}, lsp_keymaps = true, luasnip = false, max_line_len = 0, null_ls = {}, null_ls_document_formatting_disable = false, on_exit = , on_jobstart = , on_stderr = , on_stdout = , run_in_floaterm = false, sign_covered_hl = "String", sign_partial_hl = "WarningMsg", sign_priority = 7, sign_uncovered_hl = "Error", tag_options = "json=omitempty", tag_transform = false, test_efm = false, test_runner = "go", textobjects = true, trouble = false, useremail = "", username = "", verbose = false, verbose_tests = false } ```

FWIW I'm using AstroNvim's Golang pack as my base config on Neovim v0.10, if this helps.

ray-x commented 1 month ago

I think null_ls = {}, reset the settings the default is

 null_ls = {
    golangci_lint = {
      -- disable = {'errcheck', 'staticcheck'}, -- linters to disable empty by default
      -- enable = {'govet', 'ineffassign','revive', 'gosimple'}, -- linters to enable; empty by default
    },
  },
rami3l commented 1 month ago

I think null_ls = {}, reset the settings the default is

 null_ls = {
    golangci_lint = {
      -- disable = {'errcheck', 'staticcheck'}, -- linters to disable empty by default
      -- enable = {'govet', 'ineffassign','revive', 'gosimple'}, -- linters to enable; empty by default
    },
  },

@ray-x Thanks for the prompt reply! Looks like this has something to do with opts = { disable_defaults = true } in the base config. Is this breakage intentional? [^1]

I believe that _GO_NVIM_CFG.null_ls has been set to {} in:

https://github.com/ray-x/go.nvim/blob/e80846dec565dac6418334cfc4eecc087678ff69/lua/go.lua#L201-L210

[^1]: ... so in other words, it looks like changing disable_defaults in "ray-x/go.nvim"'s opts has broken golangci_lint(). IMHO this probably should not happen.

rami3l commented 1 month ago

It looks like 294d65c93514f14fbbe8af0545ab8918d939acdb has addressed the issue for me. Many thanks :)

mehalter commented 1 month ago

@ray-x just a heads up, this breaks the diagnostics disabling when calling disable_defaults. This is because diagnostics should be getting set to false.

mehalter commented 1 month ago

I'm not sure exactly if it breaks other default disabling, but it seems like not a very robust approach when the values that are expected for disabling differ between the options

ray-x commented 1 month ago

It is a bug when a value can be either bool or list. I pushed a fix for it. 4274cb3fb31113c93485877d0d2b77cc80383da9