#279, support preprocessors

[ndmitchell]

Turns out to be rather easy, since GHC exposes very reusable pieces. Works with the example in #279. CC @DoctorRyner

I don't have a great suggestion for how to test this, but I do think a test would be valuable. To do a test we need a preprocessor available with the test suite. We could require record-dot-preprocessor, but that seems a very bad idea. We could write our own small shell script, but that's going to have portability issues. Thoughts?

[pkapustin]

Thank you so much, Neil!

[aherrmann-da]

Thank you for addressing this so quickly.

Re test: We could add a simple formatter executable target to ghcide.cabal, make it a build-tool-depends for the tests, and then use it in a test-case. The formatter could be something really simple, e.g. replace x by y with a test-case like

y = 5
z = x + x

What do you think?

[ndmitchell]

If that would be sufficient, it would be great. My concern is adding another binary to the cabal package might cause it to be installed by users - but maybe that's not the end of the world.

[ndmitchell]

Test added along the lines @aherrmann-da suggests

[aherrmann-da]

My concern is adding another binary to the cabal package might cause it to be installed by users - but maybe that's not the end of the world.

Indeed, that's an annoying side-effect. I tried setting Cabal 2.0's scope attribute to private, but stack install ghcide still installed the test executable along-side ghcide.

As you say, it's probably not the end of the world. Users can run stack install ghcide:ghcide explicitly to avoid installing the test binary, if it's an issue.