Update: that type-eq uses cpphs is its own preference, encoded in its
.cabal file. That means the impact of this bug is lower than I assumed.
Can someone comment on the plans to use cpphs in ghc? I jumped to a
conclusion that this has already happened, but I definitely remember
that it was discussed. What was the conclusion?
* Roman Cheplyaka
Hi Malcolm,
This appears to be a cpphs bug. For the following code
#define x (1 == 1) #if x YES #else NO #endif
cpphs 1.18.1 prints NO, while the expected output (and the output GNU cpp produces) is YES. If parentheses around 1 == 1 are removed, or if x is inlined manually, then cpphs correctly prints YES.
This affects GHC 7.8 users in a serious way: GHC 7.8 uses cpphs, and the above code is a simplified version of macros generated by cabal.
For this reason, for instance, type-eq 0.4.1 cannot be build by GHC 7.8 RC1, despite the proper CPP guards.
Roman