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 [2014-02-21 18:04:17+0200]

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

On 21 Feb 2014, at 16:04, Roman Cheplyaka wrote:

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.

I acknowledge that this is a bug in cpphs. It is actually a bit worse than this - the following code also outputs NO with cpphs, when it should clearly be YES: #define x 0 == 0 #if x YES #else NO #endif It is all to do with the recursive expansion of symbols during parsing, where currently we are interpreting the first symbol in the expansion as the intended boolean value, rather than re-parsing the whole expanded expression. Fixing it will be a little bit more involved than just adding another clause to the parser, but I'm on it. Regards, Malcolm