This patch is meant to be applied instead of D18425, but is a new review because we're taking an entirely different approach.
This patch makes us fail enable_if conditions in a value dependent context, if not all values are present when we're trying to evaluate the enable_if. e.g.
void foo(int i) __attribute__((enable_if(i, ""))); template <int N> void callFoo() { foo(N); } // Error: No viable overload (emitted before any instantiations of callFoo are made), because the call to foo is resolved prior to instantiating callFoo, so we don't have a single value for N.
Our current behavior is that we'll happily resolve foo to the only existing foo overload, and be totally fine with callFoo<0>(); as a result, which is incorrect. Were there two foo overloads with different enable_if attributes, we would always emit an error about an ambiguous overload set.
A complete, consistent fix for this would require that we're able to arbitrarily defer overload resolution. Additionally, we would need to handle type dependence appearing out of nowhere, as in:
double bar(int N) __attribute__((enable_if(N, ""))); void *bar(int N) __attribute__((enable_if(!N, ""))); template <int N> auto callBar() { return bar(N); }
Which seems like a very large, bug-prone change.
Given that it seems no one has tried to use enable_if in a value-dependent context yet (if they were, I'd assume we would have received a bug report about bar(N) always being ambiguous by now), I think this is the least bad of all of our options.