Pass `fname` and `cwd` to `parse` function

[mothzarella]

Problem X you are solving:

Some linters output diagnostics for multiple files in a single run. For example, terraform validate always validates the entire terraform configuration and returns diagnostics for all .tf files. I need to filter diagnostics to show only those relevant to the current buffer.

Problems encountered under the status quo:

Right now, parse only gets (result, bufnr) as parameters. The issue is that parse runs inside async.run, which means it's in a fast event context where you can't call neovim api.

parse = function(result, bufnr)
  -- E5560: must not be called in a fast event context
  local fname = vim.api.nvim_buf_get_name(bufnr)
  
  -- This also doesn't work :(
  local fname = vim.fn.bufname(bufnr)
end

Suggested feature Y:

You're already capturing fname and cwd before the async context (line 82 in guard/lint.lua). Could you pass them to parse too?

-- Current (line ~107,122)
if #data > 0 then
  results = lint.parse(data, buf)
end

-- Proposed
if #data > 0 then
  results = lint.parse(data, buf, fname, cwd)
end

How to solve X now:

The only workaround I found is to capture the filename before vim.system and inject it through the linter output:

fn = function(acc)
  local co = assert(coroutine.running())
  
  vim.system({ 'terraform', 'validate', '-json' }, {...}, function(result)
    -- I also tried wrapping the code in a `vim.schedule`
    local rpath = vim.fn.expand('%:.')
    local decoded = vim.json.decode(result.stdout)
    decoded.current_file = rpath
    coroutine.resume(co, vim.json.encode(decoded))
  end)

  ...

end

I tried using vim.schedule in the callback to exit the fast context, but that breaks the coroutine flow and parse never gets called.

How can X be solved after feature Y is implmented:

parse = function(result, bufnr, fname, cwd)
  local current_file = fname:gsub('^%. /', '')
  local decoded = vim.json.decode(result)
  local diagnostics = {}
  
  for _, diag in ipairs(decoded.diagnostics or {}) do
    local diag_file = diag.range.filename:gsub('^%.  /', '')
    if diag_file == current_file then
      table.insert(diagnostics, diag)
    end
  end
  
  return diagnostics
end

[xiaoshihou514]

I mean, really this is not the kind of linter that you expect would work on a single file...

I am open to further arguments.

[mothzarella]

I think we're saying the same thing... terraform validate must validate the entire project, the problem is what guard does with the results.

Without fname I can't filter diagnostics by file. So:

Scenario:

• I have 3 files: main.tf, provider.tf, variables.tf
• provider.tf has a validation error on line 5
• I open main.tf in my buffer

1. Guard runs terraform validate (validates all 3 files)
2. Returns diagnostics for all files including the error in provider.tf
3. Guard displays the provider.tf error as virtual text in my main.tf buffer
4. I'm editing main.tf but seeing errors from provider.tf

parse = function(result, bufnr, fname, cwd)
  local diagnostics = vim.json.decode(result).diagnostics or {}
  local current = fname:sub(#cwd + 2)
  for _, d in ipairs(diagnostics) do
    local range = d.range
    if range and range.filename == current then
      ...
    end
  end
end

[xiaoshihou514]

Yes, but I hesistent to support it. Like, you won't use gradlew as a linter. Maybe there are some better linters or lsp for tf.

[mothzarella]

I get the hesitation, but this isn’t unique to terraform validate: most IaC linters like tflint (the "better" terraform validate), kubeval, helm lint, tofu lint and others analyze the whole project and output diagnostics for all files together, without a native way to filter per file.

Taking tflint as an example: while it has a --filter flag, it only restricts the output to issues directly connected to the specified file. Project-level or cross-file issues simply don’t appear when you use the filter, even if the file is involved.

It would just be a pity not to be able to use these linters effectively with guard.nvim.

[xiaoshihou514]

Ah that sounds terrible.

Anyway, I will take a look at the pr.