add to hlint known limitations in features doc, fix wrong comment in hlint plugin (#2685)

Author: eddiemundo

docs/features.md

@@ -144,6 +144,8 @@ Uses [apply-refact](https://github.com/mpickering/apply-refact).
 Known limitations:
 
 - May have strange behaviour in files with CPP, since `apply-refact` does not support CPP.
+- The `hlint` executable by default turns on many extensions when parsing a file because it is not certain about the exact extensions that apply to the file (they may come from project files). This differs from HLS which uses only the extensions the file needs to parse the file. Hence it is possible for the `hlint` executable to report a parse error on a file, but the `hlint` plugin to work just fine on the same file. This does mean that the turning on/off of extensions in the hlint config may be ignored by the `hlint` plugin.
+- Hlint restrictions do not work (yet). This [PR](https://github.com/ndmitchell/hlint/pull/1340) should enable that functionality, but this requires a newer version of hlint to be used in HLS.
 
 ### Make import lists fully explicit
 

plugins/hls-hlint-plugin/src/Ide/Plugin/Hlint.hs

@@ -288,12 +288,12 @@ getIdeas nfp = do
           return $ flags { enabledExtensions = hlintExts }
 
 -- Gets extensions from ModSummary dynflags for the file.
--- Previously this would concatenate extensions from both hlint's parsedFlags
+-- Previously this would union extensions from both hlint's parsedFlags
 -- and the ModSummary dynflags. However using the parsedFlags extensions
 -- can sometimes interfere with the hlint parsing of the file.
 -- See https://github.com/haskell/haskell-language-server/issues/1279
 --
--- Note: this is used when HLINT_ON_GHC_LIB is not defined. We seem to need
+-- Note: this is used when HLINT_ON_GHC_LIB is defined. We seem to need
 -- these extensions to construct dynflags to parse the file again. Therefore
 -- using hlint default extensions doesn't seem to be a problem when
 -- HLINT_ON_GHC_LIB is not defined because we don't parse the file again.