ndmitchell / hlint

Haskell source code suggestions
Other
1.48k stars 195 forks source link

hlint produces suggestions for code inserted by preprocessor #1245

Open andrewufrank opened 3 years ago

andrewufrank commented 3 years ago

use case: HTF wiih the pragma

{-# OPTIONS_GHC -F -pgmF htfpp #-}

produces many hints about the bracket the precompiler inserts (defensively, I think):

{
    "resource": "/home/frank/Workspace11/u4blog/uniform-pandoc/tests/Uniform/DocRep_test.hs",
    "owner": "Haskell (uniform-pandoc)",
    "code": "refact:Redundant bracket",
    "severity": 2,
    "message": "Redundant bracket\nFound:\n  (assertEqual_\n   (makeLoc\n      \"/home/frank/Workspace11/u4blog/uniform-pandoc/tests/Uniform/DocRep_test.hs\"\n      45))\n  \"DocRep {yam = Null, pan = Pandoc (Meta {unMeta = fromList []}) []}\"\nWhy not:\n  assertEqual_\n  (makeLoc\n     \"/home/frank/Workspace11/u4blog/uniform-pandoc/tests/Uniform/DocRep_test.hs\"\n     45)\n  \"DocRep {yam = Null, pan = Pandoc (Meta {unMeta = fromList []}) []}\"\n",
    "source": "hlint",
    "startLineNumber": 45,
    "startColumn": 13,
    "endLineNumber": 45,
    "endColumn": 117
}

I tried to avoid this by adding to my hlint.yaml:

- arguments: [-XNoCPP]

but did not work (I restarted HSL, what else would have been necessary), the same hints are produced (which I can not act on).

I am confused assuming that -XNoCPP would avoid running the preprocessor on my code and show me only the hints I can fix. What is my misunderstanding? How to achieve that hlint shows only user fixable things? Thank you for a VERY useful tool!

ndmitchell commented 3 years ago

If you are using HLS, then HLint sees the code after preprocessing. If you are using hlint on the command line, then it sees the code before preprocessing. For other preprocessors, e.g. record-dot-preprocessor, it emits HLint clean code, and disables the lints that it still raises - see https://github.com/ndmitchell/record-dot-preprocessor/issues/37 which disables them. I suspect that if htfpp wants to be usable with HLint through HLS it probably needs to do the same trick.

The -XNoCpp is a bit of a red herring. With HLS, it has no effect. With HLint, it only disables the C Pre Processor, not other preprocessors (which HLint itself can't deal with anyway)

andrewufrank commented 3 years ago

I see that the issue seems more complex and asking more questions than I expected. To avoid more questions, perhaps you put a note where the -XNoCpp flag is mentioned and say that it does not have an effect on HLS - saves time and head scratching.

For code with preprocessors I will use hlint on the command line when I really need it. usually I can ignore the effects when looking at the hints and warnings fro hlint.

In general, i find hlint very helpful, especially when pointing out unused things. what I would wish for, but which is not in the design enveloppe, are unused imports, unused dependencies and, especially, unused functions. HLS makes good progress and might eventually help with these. - thank you for your help over the years! andre

georgefst commented 3 years ago

what I would wish for, but which is not in the design enveloppe, are unused imports, unused dependencies and, especially, unused functions

If I understand correctly, GHC itself is capable of warning about these. You just need -Wall and the recently-added -Wunused-packages. And the warnings will show up nicely in HLS.