[PATCH] Fix regression with noexcept

[Aaron Ballman]

I've revised the test case in this patch, as Richard pointed in
PR15842, that code is actually ill-formed (as well as David's comment
about the utility of having both tests).

~Aaron

On Fri, Apr 10, 2015 at 2:08 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
> 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
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: noexcept_v2.patch
Type: application/octet-stream
Size: 1472 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150410/e8ab24c1/attachment.obj>