From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30655 invoked by alias); 14 Feb 2012 16:46:00 -0000 Received: (qmail 30621 invoked by uid 22791); 14 Feb 2012 16:45:56 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Feb 2012 16:45:42 +0000 From: "paolo.carlini at oracle dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/44783] implement -ftemplate-backtrace-limit= Date: Tue, 14 Feb 2012 16:46:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: paolo.carlini at oracle dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-02/txt/msg01438.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44783 --- Comment #12 from Paolo Carlini 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.