<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 December 2014 at 14:25, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>+ if (EIA->getCond()->isValueDependent()) {<br></div><div>+ // Don't even try now, we'll examine it after instantiation.</div><div>+ continue;</div><div>+ }</div><div><br></div><div>Is this sufficient? Suppose we have:</div><div><br></div><div>template<bool B> struct S {</div><div> void f() __attribute__((enable_if(B, "")));</div><div> void f() __attribute__((enable_if(!B, "")));<br></div><div> void g() { f(); }</div><div>};</div><div><br></div><div>Will we reject the template due to the amiguity in overload resolution for f()? (If not, what saves us?) </div></div></blockquote><div><br></div><div>We do not. With just this TU, we never even get into overload resolution. Sema::ActOnCallExpr saves us by bailing very early producing a dependent CallExpr before even trying to build a member function call, because g()'s type is type dependent. See the comment "Determine whether this is a dependent call inside a C++ template, in which case we won't do any semantic analysis now" in SemaExpr.cpp.</div><div><br></div><div>If it had gone through AddOverloadCandidate, it would call CheckEnableIf which would return that no enable_if expression had failed, and we would build up an overload candidate set with two equally ranked candidates, but that isn't an error yet. Whoever would be doing that would also need to handle the case of:</div><div><br></div><div> void f(X);</div><div> void f(Y);</div><div> template<typename T> void g() { f(T()); }</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Likewise for:</div><div><br></div><div><div>template<bool B> struct S {</div><div> void f(bool b) __attribute__((enable_if(b, "")));</div><div> void f(bool b) __attribute__((enable_if(!b, "")));</div><div> void g() { f(B); }</div><div>};</div></div></div></blockquote><div><br></div><div>Again no error for the same reasons.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>+// FIXME: issue an error (without instantiation) because h(T()) is not<br></div><div><div>+// convertible to bool, because return types aren't overloadable.</div><div>+void h(int);</div><div>+template <typename T> void outer() {</div><div>+ void local_function() __attribute__((enable_if(h(T()), "")));</div><div>+ local_function();</div><div>+};</div></div><div><br></div><div>This FIXME doesn't seem correct: a different 'h' could be found by ADL, and it could be a constexpr function returning bool. What happens if you use ::h instead?</div></div></blockquote><div><br></div><div>Good catch! I had forgotten about ADL here.</div><div><br></div><div>I get the same thing with ::h, also (h) and (::h). I'll update the code and comment to use ::h.</div><div><br></div><div>Nick</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>LGTM with the FIXME corrected; we can fix the semantics of the dependent case (if it's not working) after the crash is fixed.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Dec 8, 2014 at 8:43 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">The attached patch improves our handling of value dependent expressions in attribute((enable_if)), both in the condition expression and at the call site. Fixes PR20988.<div><br></div><div>Please review!</div><span><font color="#888888"><div><br></div><div>Nick</div><div><br></div></font></span></div>
<br></div></div>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div>