Improve hlint cpp support using the preprocessed buffer

[jneira]

• As suggested by @ndmitchell here
• It enables hlint suggestions for files with cpp conditions and ghc < 8.10

[ndmitchell]

Awesome - looks good to me.

[jneira]

After doing a manual test i've found that the code span of the hlint diagnostics using the preprocessed buffer doesnt match the real file. That was not tested and it should be cause i suspected it could be happen: #554 (comment)

@ndmitchell i understood from your comment that the code spans would be honoured in the preprocessed but it seems that if it is not the case afaics.

To make it work we should recover the original source spans from the preprocessed one to correct the diagnostic and not sure if it will worth (over other alternatives like extract cpp flags from the ghc session and pass them to hlint) 😟

[ndmitchell]

What should happen is the preprocessor should drop {-# LINE #-} pragmas, which GHC should honour when building the AST. Are the LINE pragmas being produced? And are they being honoured?

[jneira]

Mmm, i've kept the hspp intermediate file with ghc -keep-hscpp-file -tmpdir . -XCPP .\ApplyRefact2.hs

being .\ApplyRefact2.hs

module ApplyRefact2 where

#include "test.h"

#ifdef TEST
f = (1)
#else
f = 1
#endif

And the file in the line 215 of ApplyRefact2.hscpp:

# 8 "<command-line>" 2
# 1 "ApplyRefact2.hs"
module ApplyRefact2 where


# 1 "test.h" 1
# 4 "ApplyRefact2.hs" 2


f = (1)

Not sure if lines should be there

[ndmitchell]

OK, so GHC is dropping the # line number prefixes. That's a bit surprising, but I think is supported by HLint (or rather, by GHC). However, I think cpphs probably removes them. So you may need to pass NoCpp to the parseModuleEx function of HLint - which kind of makes sense, give you have already handled CPP. Does that help?

(And sorry for taking so long to respond, I'm miles deep in a pile of emails)

[jneira]

dont have time to continue working on this, feel free to reuse it