From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21896 invoked by alias); 14 Dec 2010 08:37:15 -0000 Received: (qmail 21888 invoked by uid 22791); 14 Dec 2010 08:37:15 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-qw0-f47.google.com (HELO mail-qw0-f47.google.com) (209.85.216.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Dec 2010 08:37:10 +0000 Received: by qwg5 with SMTP id 5so264540qwg.20 for ; Tue, 14 Dec 2010 00:37:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.230.10 with SMTP id jk10mr4664270qcb.105.1292315827955; Tue, 14 Dec 2010 00:37:07 -0800 (PST) Received: by 10.229.75.70 with HTTP; Tue, 14 Dec 2010 00:37:07 -0800 (PST) In-Reply-To: References: <1291979498-1604-1-git-send-email-dodji@redhat.com> <1291979498-1604-5-git-send-email-dodji@redhat.com> <4D063157.3050901@gnu.org> Date: Tue, 14 Dec 2010 09:38:00 -0000 Message-ID: Subject: Re: [PATCH 3/6] Emit macro expansion related diagnostics From: Gabriel Dos Reis To: Dodji Seketeli Cc: Paolo Bonzini , gcc-patches@gcc.gnu.org, tromey@redhat.com, joseph@codesourcery.com, lopezibanez@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-12/txt/msg01076.txt.bz2 On Tue, Dec 14, 2010 at 2:22 AM, Dodji Seketeli wrote: >> However, models to look for are print_candidates(), >> cxx_print_error_function, the newly introduced >> qualified_name_lookup_errorr, etc. > > I see. Though, some of these functions call below the level error and > inform by calling pp_base_set_prefix, pp_verbatim and the like. Are > those pp_* calls intended as well? Yes, that is another dimension to the diagnostic machinery. The idea here is that every client (i.e. front-end) may have som front-end specific actions to take (e.g. printing template instantiation contexts) before the core diagnostic message is printed. That is the role of `diagnostic starter' functions (see the comments in diagnostic.h). Similarly we have `diagnostic finalizer' functions which are supposed to do any sort of `cleanup' after a diagnostic is printed. Now, you can consider CPP as a sort of front-end that turns raw input file into a stream of tokens which is then handed over to the C or C++ parsers -- but I'm not sure that is the way it currently works. So, another option is to find a combination of these two dimensions. > >> >> The point here is that I would expect CPP to define its own error print >> diagnostic function that tracks macro expansion context >> (at bit like what what we do with template instantiation contexts) >> and combine calls to error_at() and inform(). > > Okay, so I guess I will move the macro expansion unwinder into CPP and > make it and use the CPP diagnostic routines that in turn use c_cpp_error > (via the cpp_reader callbacks) that is at the same level as inform() > error() etc. It is my belief that the macro-expansion related diagnostics specific improvements belong there. > > I will still have to make default_diagnostic_finalizer call that > unwinder to make macro expansion context be printed implicitely, though. something you can't do with CPP specific diagnostic finalizer? -- Gaby