[PATCH] Fix regression with noexcept

[Aaron Ballman]

Ping?

On Fri, Apr 10, 2015 at 5:34 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
> 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
>>>
>>>