cpphs bug

[Roman Cheplyaka]

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 <roma at ro-che.info> [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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140221/2a4039e8/attachment.sig>