From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25801 invoked by alias); 26 Oct 2004 01:03:29 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 25784 invoked from network); 26 Oct 2004 01:03:28 -0000 Received: from unknown (HELO lon-mail-1.gradwell.net) (193.111.201.125) by sourceware.org with SMTP; 26 Oct 2004 01:03:28 -0000 Received: from digraph.polyomino.org.uk [81.187.227.50] (user: postmaster6815c918op3.polyomino.org.uk) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.147) id 417da25e.177b6.78; Tue, 26 Oct 2004 02:03:26 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.42) id 1CMFkE-0003h2-3u; Tue, 26 Oct 2004 01:03:26 +0000 Date: Tue, 26 Oct 2004 01:11:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Zack Weinberg cc: Andrew Pinski , gcc-patches@gcc.gnu.org Subject: Re: New C parser [patch] In-Reply-To: <87u0sico98.fsf@codesourcery.com> Message-ID: References: <873c02e46k.fsf@codesourcery.com> <87u0sico98.fsf@codesourcery.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-10/txt/msg02142.txt.bz2 On Mon, 25 Oct 2004, Zack Weinberg wrote: > > But I will say that we have C++ diagnostic regressions because of > > "%<%>ifying". The reason why we have this problem is because > > c_parser_error takes a string but only does %s on it rather than passing > > it on to the diagnostic mechanism. > > c_parse(r)_error have serious i18n issues already: I don't think this > one more makes much difference. The way forward is to remove > c_parse_error entirely... The regressions in English messages in the C++ front end are separate from the i18n problems. For now, my parser uses literal '' to get properly formatted English messages. When this area is cleaned up, or if c_parse_error starts accepting %<%>, then it can start using %<%>. For now, the i18n is no worse than with the existing parser, and a key design feature of this patch is that it tries to be as minimal as possible for a parser replacement: it will follow cleanups made to the existing code before it goes in, and it will facilitate further cleanups once it is in, but will avoid leading on cleanups or changes that don't need entangling with a new parser. I will however put ??? comments anywhere (as here) where it is suggested that the status quo is a mess and a good subject for a future cleanup. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ jsm@polyomino.org.uk (personal mail) joseph@codesourcery.com (CodeSourcery mail) jsm28@gcc.gnu.org (Bugzilla assignments and CCs)