Test case:
int foo(int A) __attribute__((enable_if(A == 0, ""))); template <int A> int bar() { return foo(A); } int G = bar<1>(); // calls foo(1), which should be a compile-time error, but isn't.
We get around this by making CheckEnableIf fail all value dependent enable_if conditions, and report whether the condition may have failed due to a dependent value. If we fail for this reason during overload resolution, we hand back an unresolved, type-dependent call expression, because the following code is perfectly legal:
int ThisIsABadIdea(int A) __attribute__((enable_if(A == 1, ""))); double ThisIsABadIdea(int A) __attribute__((enable_if(A == 2, "")));
...But if we're not in overload resolution, we can get away with just marking the expression as value dependent, because we know our target. :)
I'd just call this Dependent -- that is, "here is a dependent enable_if attribute, so I couldn't tell whether this is enabled". The details of why it's dependent shouldn't be relevant to the caller.