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 <[email protected]> [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
signature.asc
Description: Digital signature
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
