<div dir="ltr">I'll leave the language lawyering double-check to Richard.<br><br>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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 10, 2015 at 10:56 AM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When working on diagnosing unevaluated expressions with side effects,<br>
a regression crept in with seemingly valid code involving noexcept<br>
expression that would receive an unresolved expression, such as:<br>
<br>
template <class T> void f() {}<br>
int v = noexcept(&f);<br>
<br>
This code compiles without warning in gcc, and used to do the same in<br>
Clang (and result in v being set to 1), but currently causes an<br>
unreachable assertion. This is captured in PR22072.<br>
<br>
This patch fixes the unreachable assertion. I believe it is reasonable<br>
to expect unresolved expressions in HasSideEffects, and those<br>
expressions would not have side effects. However, it may also be that<br>
the noexcept code is ill-formed (see PR15842 for a similar situation,<br>
which also currently asserts), and the correct fix is to diagnose the<br>
code as a failed parameter to the noexcept expression.<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span></blockquote></div><br></div>