From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11511 invoked by alias); 14 Dec 2010 09:23:03 -0000 Received: (qmail 11498 invoked by uid 22791); 14 Dec 2010 09:23:02 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Dec 2010 09:22:58 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBE9Mnuv001797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Dec 2010 04:22:50 -0500 Received: from adjoa.redhat.com (ovpn-113-36.phx2.redhat.com [10.3.113.36]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oBE9MiQe025160; Tue, 14 Dec 2010 04:22:45 -0500 From: Dodji Seketeli To: Gabriel Dos Reis Cc: Paolo Bonzini , gcc-patches@gcc.gnu.org, tromey@redhat.com, joseph@codesourcery.com, lopezibanez@gmail.com Subject: Re: [PATCH 3/6] Emit macro expansion related diagnostics References: <1291979498-1604-1-git-send-email-dodji@redhat.com> <1291979498-1604-5-git-send-email-dodji@redhat.com> <4D063157.3050901@gnu.org> X-URL: http://www.redhat.com Date: Tue, 14 Dec 2010 09:42:00 -0000 In-Reply-To: (Gabriel Dos Reis's message of "Tue, 14 Dec 2010 02:37:07 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg01078.txt.bz2 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. 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. OK. And front-ends are supposed to be able to provide their own diagnostics starter and finalizer functions. > 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. A sort of front-end indeed. [..] >> 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? 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. -- Dodji