From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8109 invoked by alias); 14 Dec 2010 09:38:16 -0000 Received: (qmail 8100 invoked by uid 22791); 14 Dec 2010 09:38: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 09:38:08 +0000 Received: by qwg5 with SMTP id 5so323221qwg.20 for ; Tue, 14 Dec 2010 01:38:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.229.200 with SMTP id jj8mr4674729qcb.295.1292319486008; Tue, 14 Dec 2010 01:38:06 -0800 (PST) Received: by 10.229.75.70 with HTTP; Tue, 14 Dec 2010 01:38:05 -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:48: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 Content-Transfer-Encoding: quoted-printable 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/msg01080.txt.bz2 On Tue, Dec 14, 2010 at 3:22 AM, Dodji Seketeli wrote: > Gabriel Dos Reis writes: > > [...] > >>> 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. =A0That >> is the role of `diagnostic starter' functions (see the comments >> in diagnostic.h). =A0Similarly we have `diagnostic finalizer' functions >> which are supposed to do any sort of `cleanup' after a diagnostic >> is printed. > > OK. And front-ends are supposed to be able to provide their own > diagnostics starter and finalizer functions. yes. [..] >>> 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? > > Good catch. The thing is CPP is used like a library by the front-end (C, > C++, Fortran) that needs to consume the tokens it generates. As such, > CPP itself doesn't override the diagnostic finalizer. It's the front-end > that does it. And right now the C and Fortran FEs just use the default > diagnostic finalizer. > > If I underrstand correctly, I should now provide a specific diagnostic > finalizer for C and Fortran FEs (like what G++ does) and have them call > the macro expansion unwinder (that would be) provided by CPP and leave > default_diagnostic_finalizer alone. yes, that sounds good.