Fix hlint parsing file with disabled extension #2671
Conversation
There was a problem hiding this comment.
This seems sensible to me. My understanding is that the reason for listing extensions in .hlint.yaml is that hlint can't otherwise know what extensions GHC would in fact be using to compile that file. But here we really do know, which seems superior.
However, this reasoning isn't completely obvious, s ocould you add a comment? Perhaps write a doc comment for getExtensions that explains which extensions we get?
…ces section to hlint plugin readme
…server into hlint-parse-disabled-exts-fix
| ## Known Differences from the `hlint` executable | ||
|
|
||
| - 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. |
There was a problem hiding this comment.
This should maybe be in a "known limitations" section on the features page too?
There was a problem hiding this comment.
Yes, I'll add that.
| debugm $ "hlint:getIdeas:setExtensions:" ++ show hlintExts | ||
| return $ flags { enabledExtensions = hlintExts } | ||
|
|
||
| getExtensions :: ParseFlags -> NormalizedFilePath -> Action [Extension] | ||
| getExtensions pflags nfp = do | ||
| -- Gets extensions from ModSummary dynflags for the file. |
There was a problem hiding this comment.
Argh, there's a somewhat important typo. It's supposed to be, "this is used when HLINT_ON_GHC_LIB is defined" instead of "is not". Gonna add it to the features.md known limitations PR.
Seems to fix #1279
All I did was not use the extensions that hlint turns on by default, and only use extensions found via the mod summary. The mod summary seems to also include extensions listed under the
extensionsstanza in the cabal file.Not fully certain this doesn't break somebody's workflow.
If someone turns on an extension in the
hlint.yamland expectshlintto always consider it on I think that will conflict with this fix because I don't know how to disambiguate between an extension that is turned on by default byhlintand an extension turned on by the user in thehlint.yaml.