[PATCH] Improve error reporting for SFINAE

paul Fultz pfultz2 at yahoo.com
Mon Apr 6 15:06:05 PDT 2015


> The difference is, the current diagnostics allow the user to figure out what
> happened. This change does not -- there's no way to find out which 'f' caused
> the problem, and how we got from 'f' to 'g'.

Yes, the user can still figure out how you got from `f` to `g`. The user can
either add an extra overload for `g` or comment out `g`(and continue so until
the user gets to `f`). So instead of working forwards from `f` to `g`, the
user just works backwards from `g` to `f`. However, its less likely a user
would need to do that since 90% of the time users want to get to `g` and not
to `f`.

Paul
 



     On Monday, April 6, 2015 4:24 PM, Richard Smith <richard at metafoo.co.uk> wrote:
   
 

 On Mon, Apr 6, 2015 at 2:08 PM, Paul Fultz II <pfultz2 at yahoo.com> wrote:

> gives the user no idea of how we got from a call to f into a call to g.

For the default case, its better to show the first and last in the trace, as most users don't care about the intermediate steps.

> If we produced a stack of 'in instantiation of' notes, this would be fine

Yes, the full back trace can be added in the future(perhaps as a compiler flag). This is the first step towards that direction. There needs to be some refactoring to `DeductionFailureInfo` so it stores the entire diagnostics(rather than a single diagnostic) to make a full back trace possible.

The difference is, the current diagnostics allow the user to figure out what happened. This change does not -- there's no way to find out which 'f' caused the problem, and how we got from 'f' to 'g'. Hence this patch is not acceptable as-is -- not even as a stepping stone to something better.

> note that's exactly what my patch in comment#1/comment#2 of that bug does

That seemed to be more of a hack then something to be used in production.

Yes, absolutely, that change is not production-ready.

 
   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150406/e445f8a0/attachment.html>


More information about the cfe-commits mailing list