cpphs bug

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

cpphs bug

Roman Cheplyaka-2
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

Reply | Threaded
Open this post in threaded view
|

cpphs bug

Roman Cheplyaka-2
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>

Reply | Threaded
Open this post in threaded view
|

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>

Reply | Threaded
Open this post in threaded view
|

cpphs bug

Malcolm Wallace-2
In reply to this post by Roman Cheplyaka-2

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

Reply | Threaded
Open this post in threaded view
|

cpphs bug

Malcolm Wallace-2

>> 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

OK, bug now fixed in version 1.18.2.

Regards,
    Malcolm