[PATCH] Fix regression with noexcept

[Aaron Ballman]

I am retracting this patch; it was resolved more appropriately with r235931. :-)

~Aaron

On Thu, Apr 23, 2015 at 11:31 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
> 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
>>>>
>>>>