[RFC / Patch] PR 51305

[Paolo Carlini]

Hi again,
> Hi,
>
> this is a rejects-valid with constexpr & noexcept, noticed by Daniel 
> (and myself time ago). I find it pretty annoying. Anyway, the issue 
> is, we reject:
>
> constexpr bool ok() noexcept
> {
>   typedef int type;
>   return true;
> }
>
> constexpr auto x = ok();
>
> because of the noexcept. What happens is that massage_constexpr_body 
> looks inside MUST_NOT_THROW_EXPR but then doesn't notice that body is 
> still a BIND_EXPR.
>
> Thus the obvious idea is processing the latter as we would do if the 
> noexcept were not there and that indeed fixes the issue without 
> regressions, but I'm not sure if we shouldn't recurse / iterate more 
> generically (or do indeed something else entirely)
uhm, if all there is to this issue is just the possibility of a 
BIND_EXPR embedded inside a MUST_NOT_THROW_EXPR we could just trivially 
reorder the conditionals of course (the current order seems just 
accidental). Or, assuming nothing deeper is going on, we can iterate. 
Both patchlets below pass testing.

Thanks,
Paolo.

////////////////////
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: p2
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20111221/28e644af/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: p3
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20111221/28e644af/attachment-0001.ksh>