[Bug c++/44783] implement -ftemplate-backtrace-limit=

["paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44783

--- Comment #12 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-02-14 16:45:20 UTC ---
> Any number of notes will be matched by a single "note:" test, since the
> testsuite does not detect duplicates. There is PR about this somewhere.

I'm not sure the issue is just about duplicates. I know that. I'm afraid there
is more, like if a testcase doesn't have *any* dg-message markup it can pass,
like the actual *text* in a dg-message doesn't matter, things like that. I can
easily provide examples of the former, probably as easily the latter too.

> > Anyway, about the code, if I understand correctly your explanation, 'n_total >
> > template_backtrace_limit + 1' would lead to the exact same default behavior we
> > have now, but appears to misbehave a little when template_backtrace_limit == 1
> > and n_total == 2 because we really want 1 note in that case, that is what the
> > user really asked, right? Then probably what you wrote in the draft is fine,
> > but I don't have a strong opinion, really, I only noticed something 'weird'
> > going on with that condition and decided to ask.
> 
> So I used the testcase testsuite/g++.dg/cpp0x/noexcept15.C to play a bit. 
> 
> I noticed that my earlier version never prints "skipping 1 instantiation
> contexts". Now I recall that this was done on purpose. It seems pointless to
> print a line "skipping 1" instead of the actual instantiation context. Also, we
> don't have to deal with singular/plural. ;-)
> 
> However, this means that in some cases, we would actually print one more than
> the limit. If we just say that the limit is a limit not the exact number
> printed, a workaround is to print one less in that case. So:
> 
> limit n_total printed skipped
> 5     5       5       0
> 5     7       5       2
> 5     6       4       2
> 
> I also added the option name to the message for convenience (clang also does
> this if I recall correctly).

Ok. I'm going to regtest the updated draft. Note, in general '&&' goes always
in a new line; also cut & pasting in the trail often leads to diffs hard to
manage, better attaching, imo.