Hlint restriction (and some other) settings not working

[tgiannak]

This differs from #1260 because even the .hlint.yaml file in the root of the workspace is not being used.

Your environment

Which OS do you use:
ArchLinux, MacOS

Which LSP client (editor/plugin) do you use:
emacs+lsp-mode

Describe your project (alternative: link to the project):
GHC 8.10.7, cabal 3.6.2.0, hls 1.5.1, all installed with ghcup. hlint 3.3.4 installed with cabal.

A freshly initialized cabal project in a freshly initialized git repository with .hlint.yaml at the root of the repository:

- functions:
  - {name: nub, within: []}

Steps to reproduce

Import and use nub in src/MyLib.hs. Running hlint . in the root of the repository emits a warning about the use of nub.

Expected behaviour

The language server should also have a warning about the use of nub, as specified by the HLint configuration.

Actual behaviour

No matter what is included in HLint configuration, the language server reports HLint warnings from the default HLint config and nothing else.

Include debug information

Overwriting the Hint returned by argsSettings here with mempty does remove all hints, so it seems that argsSettings isn't behaving as expected, which aligns with this HLint issue.

[eddiemundo]

HLS actually is using .hlint.yaml.

It seems like the issue is that the functions restriction setting doesn't work because that setting (among others) is actually discarded by argsSettings for reasons I don't know.

This wouldn't be a problem if we called the hlint function directly, but we use argsSettings et. al., because (I think) we don't want hlint to do more work than necessary since we have change tracking, and already parsed files.

I don't really know a way to work around this, there might be some way of running hlint on specific files and obviating the argsSettings, applyHints usage while still not having hlint do too much work, but not sure. The other way is to see if upstream can change things so that argsSettings, applyHints give and take the more general Settings instead of discarding some of them.

[tgiannak]

Just in case I have time to dig in further, where is HLS referring to .hlint.yaml? I saw it being used in an older version of the HLint plugin (which replicated some of the behavior of the hlint settings-reading functionality instead of using argsSettings) while figuring out that argsSettings was the likely source of the problem I described, but git grep "hlint.yaml" now only shows references to the filename in test cases and in HLS's own CI configuration.

[eddiemundo]

HLS itself doesn't actually look for the .hlint.yaml although I think you can specify a location in a plugin config as a flag which we eventually pass to argsSettings. It's actually hlint's argsSettings that eventually looks for the file. It calls cmdHintFiles and the search seems to happen there by recursively looking at parent directories, or using the home directory if an explicit set of hlint config files aren't given.

[tgiannak]

Thanks, that clears it up. It looks like the upstream changes are non-trivial. I'll ask about it in the HLint issue tracker.