patch: improve handling of value dependent exprs in CheckEnableIf

Richard Smith richard at metafoo.co.uk
Mon Dec 15 14:25:25 PST 2014


+    if (EIA->getCond()->isValueDependent()) {
+      // Don't even try now, we'll examine it after instantiation.
+      continue;
+    }

Is this sufficient? Suppose we have:

template<bool B> struct S {
  void f() __attribute__((enable_if(B, "")));
  void f() __attribute__((enable_if(!B, "")));
  void g() { f(); }
};

Will we reject the template due to the amiguity in overload resolution for
f()? (If not, what saves us?) Likewise for:

template<bool B> struct S {
  void f(bool b) __attribute__((enable_if(b, "")));
  void f(bool b) __attribute__((enable_if(!b, "")));
  void g() { f(B); }
};


+// FIXME: issue an error (without instantiation) because h(T()) is not
+// convertible to bool, because return types aren't overloadable.
+void h(int);
+template <typename T> void outer() {
+  void local_function() __attribute__((enable_if(h(T()), "")));
+  local_function();
+};

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?

LGTM with the FIXME corrected; we can fix the semantics of the dependent
case (if it's not working) after the crash is fixed.

On Mon, Dec 8, 2014 at 8:43 PM, Nick Lewycky <nlewycky at google.com> wrote:

> 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.
>
> Please review!
>
> Nick
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141215/eb5d7e2e/attachment.html>


More information about the cfe-commits mailing list