cpphs bug

[Carter Schonwald]

There's actually quite a bit of hacking to make ghc properly support
decoupling the Haskell cpp and c compiler. Nothing has been merged in yet.
 I've some (incomplete) patches with the help of a few other folks, and
Austin might be doing some exploratory also.

The engineering needed to support cpphs is also exactly what's needed to
make the Haskell cpp choice easy to change in the ghc settings files etc

On Friday, February 21, 2014, Roman Cheplyaka <roma at ro-che.info> wrote:

> 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 <javascript:;>> [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 --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140221/8689e827/attachment.html>