I am retracting this patch; it was resolved more appropriately with r235931. :-)
~Aaron On Thu, Apr 23, 2015 at 11:31 AM, Aaron Ballman <[email protected]> wrote: > Ping? > > On Fri, Apr 10, 2015 at 5:34 PM, Aaron Ballman <[email protected]> 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 <[email protected]> >> wrote: >>> On Fri, Apr 10, 2015 at 2:05 PM, David Blaikie <[email protected]> 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 <[email protected]> >>>> 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 >>>> >>>> _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
