+ 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 <[email protected]> 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
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
