
On Fri, Jul 6, 2012 at 6:17 PM, Eric Niebler <eric@boostpro.com> wrote:
On 7/6/2012 5:43 PM, Nathan Ridge wrote:
From: doug.gregor@gmail.com On Fri, Jul 6, 2012 at 1:23 PM, Eric Niebler <eric@boostpro.com> wrote:
On 7/6/2012 12:54 PM, Marc Glisse wrote:
On Fri, 6 Jul 2012, Eric Niebler wrote:
The end result is that the user is presented with an error like: "no viable function A, template substitution failed." The user is given no information about which function in the chain failed to compile, or why. This is a serious usability problem!
... in your compiler.
All suggestions welcome,
Use g++. <snip informative backtrace>
Ah! Thanks. I'm using clang. I agree, it's a compiler QoI issue. I'll follow up with them.
FWIW, top-of-tree Clang produces:
t.cpp:12:3: error: no matching function for call to 'f' f(0); ^ t.cpp:8:8: note: candidate template ignored: substitution failure [with T = int]: no matching function for call to 'g' auto f(T x) -> decltype(g(x)) { return g(x); }; ^ ~
Which could probably still be improved, although I can't convince myself that GCC 4.8 is doing us favors by producing the complete SFINAE backtrace.
I think that as a matter of principle, more information is better than less. The raw error message can relatively easily be parsed by a tool that filters out undesired detail, but if the detail is not emitted in the first place, it's gone.
I'd like to second what Nate said. My experience is that not providing the backtrace is a usability nightmare. To me, this is *exactly* analogous to a template instantiation backtrace and should, IMO, be handled exactly the same way. If you want to snip the middle of the backtrace, fine, but show the start and the end (the deepest point, I guess), and perhaps provide an option for dumping the complete thing.
The typical complaints about template error messages concern excess verbosity rather than a lack of detail, so simply providing the full backtrace in all cases is not necessarily helpful. A more nuanced approach that provides this detail when it is interesting (e.g., only one candidate needs it) would be ideal; failing that, some command-line options to dial up the verbosity would allow experts to get the information they need while not flooding the terminals of the majority of C++ programmers. This is certainly worth of a Clang bug: http://llvm.org/bugs/ - Doug