Keep the output of the CPP preprocessor phase as .hspp files. A .hspp file is only created, if a module gets compiled and uses the preprocessor.
- rGHC Glasgow Haskell Compiler
Lint Errors Excuse: Lint errors are in T12971. My changes are in T10869.
No Unit Test Coverage
- Build Status
Buildable 21368 Build 48355: [GHC] Linux/amd64: Continuous Integration Build 48354: [GHC] OSX/amd64: Continuous Integration Build 48353: [GHC] Windows/amd64: Continuous Integration Build 48352: arc lint + arc unit
This is my first contribution to GHC, where I wrote real Haskell code. Therefore this is just a draft version and it needs some additional improvments.
1: CPP processing. See: ./compiler/main/DriverPipeline.hs.runPhase (RealPhase (Cpp sf)) (ca line 940):
When the -keep-hspp-file flag is set, the output file of the CPP preprocessor is copied to the *.hspp file.
2: END processing See: ./compiler/main/DriverPipeline.hs.pipeLoop (ca line 680):
The output of the last compiler phase is copied. With the -E option, GHC processing stops early and copies the output of the CPP phase to the *.hspp file.
If the user specifies both flags -E and -keep-hspp-file, then the file will be copied a first time in my new code during CPP processing and a second time here.
This is bad! Therefore I added code to avoid duplicate copying.
However, with the -E flag set, it would be better to skip the copying during CPP processing.
Unfortunately I was unable to check the -E flag in the CPP processing code! The "Mode Flags" like the -E flag, only exist in ./ghc/Main.hs.
I didn't find anything like gopt for the mode flags!! How can I check them??
I looked at the 'stop_phase' field in the PipeEnv Structure, but with or without the -E flag, it has the same value (Hsc).
Please advice! Many thanks!
Thanks for your contribution @RolandSenn!
The patch itself looks great. However, do you suppose you could amend the differential summary to describe what the patch is doing?
Can you wrap the .hspp in quotes? Also, replace "precompiler" with "preprocessor".
@bgamari : You wrote:
However, do you suppose you could amend the differential summary to describe what the patch is doing?
What do you exactly mean by this? Should I change/improve the description in docs/users_guide/separate_compilation.rst? Or do you simply mean the two little changes (quotes and preprocessor)? Please advice! Many thanks!
The differential summary (the bit shown under the "Summary" heading of this page) will become the commit message when this patch is landed. I was simply suggesting that you add a bit of text describing the goal of the patch for posterity.