[PATCH] Fix regression with noexcept

Aaron Ballman aaron at aaronballman.com
Fri Apr 10 11:08:10 PDT 2015


On Fri, Apr 10, 2015 at 2:05 PM, David Blaikie <dblaikie at gmail.com> wrote:
> I'll leave the language lawyering double-check to Richard.
>
> As for the test case - I'd just include one of the two. My example was just
> an attempt to experiment with things - whichever you reckon is simpler seems
> fine to me unless they exercise interestingly different codepaths.

Your test case turns out to be identical to the one Richard had in
PR15842, actually. They don't exercise particularly different code
paths, but since both cases were broken and both were with likely-ish
code, I figured there would be value in extending the coverage. I
don't have strong feelings on which case is "most interesting" though.

~Aaron

>
> On Fri, Apr 10, 2015 at 10:56 AM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>>
>> When working on diagnosing unevaluated expressions with side effects,
>> a regression crept in with seemingly valid code involving noexcept
>> expression that would receive an unresolved expression, such as:
>>
>> template <class T> void f() {}
>> int v = noexcept(&f);
>>
>> This code compiles without warning in gcc, and used to do the same in
>> Clang (and result in v being set to 1), but currently causes an
>> unreachable assertion. This is captured in PR22072.
>>
>> This patch fixes the unreachable assertion. I believe it is reasonable
>> to expect unresolved expressions in HasSideEffects, and those
>> expressions would not have side effects. However, it may also be that
>> the noexcept code is ill-formed (see PR15842 for a similar situation,
>> which also currently asserts), and the correct fix is to diagnose the
>> code as a failed parameter to the noexcept expression.
>>
>> ~Aaron
>
>



More information about the cfe-commits mailing list