> 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 <[email protected]>
wrote:
On Mon, Apr 6, 2015 at 2:08 PM, Paul Fultz II <[email protected]> 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.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
