From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12376 invoked by alias); 9 Aug 2007 02:36:03 -0000 Received: (qmail 12215 invoked by uid 22791); 9 Aug 2007 02:36:02 -0000 X-Spam-Check-By: sourceware.org Received: from caip.rutgers.edu (HELO caip.rutgers.edu) (128.6.236.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 09 Aug 2007 02:36:00 +0000 Received: from caipclassic.rutgers.edu (caipclassic.rutgers.edu [128.6.237.54]) by caip.rutgers.edu (8.13.8/8.13.5) with ESMTP id l792Zsqq012466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2007 22:35:54 -0400 Date: Thu, 09 Aug 2007 02:36:00 -0000 From: "Kaveh R. GHAZI" To: DJ Delorie cc: gcc-patches@gcc.gnu.org Subject: Re: Add a __nowarn__ keyword In-Reply-To: <200708082254.l78MsIC8014802@greed.delorie.com> Message-ID: References: <46B9F0B5.1080302@gnu.org> <200708082254.l78MsIC8014802@greed.delorie.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: 2007-08/txt/msg00556.txt.bz2 On Wed, 8 Aug 2007, DJ Delorie wrote: > > > If you're saying that, by design, your pragma interface only allows a > > once-per-file setting that must come before all function definitions, then > > it isn't suited to do what I want. I need something that allows > > per-statement warning silence, then reset to whatever was before, and then > > do that as many times as necessary. > > Right. The current interface has two parts: The master table of what to do > with each diagnostic, and the #pragma to change the table. What's missing > are two things: > > 1. A chain of "what changed" with back pointers, so we can implement > push/pop, nested settings, and a "revert" option, and > > 2. A way to associate a link on that chain with a point in the program > in a meaningful way. It's the "meaningful way" that was hard to > define back then. > > Anyway, item 1 is relatively easy, but not useful (or at least > ill-defined) without completing #2. #2 is hard. > > Now, if a __warn__ syntax is well-defined, perhaps we could add item > #1 as a way to implement it? If we go with __nowarn__ (or __warn__) I believe the syntax is well defined since it mimics the long-standing __extension__ behavior. It cleanly handles the push/pop paradigm because the handler code resides in the parser. Any time it sees the __extesion__ or __nowarn__ token, the parser saves the current value of the warning flag, consumes the token and recurses parsing. When the recursion returns, it restores the old value of the warning flag in question and proceeds. Simple. One potential problem is if warnings are emitted from elsewhere than in the parsing stage. E.g. if a warning comes from the middle-end, then possibly __nowarn__ doesn't get to intercept it using this mechanism. I don't know if this occurs in practice, and if so whether it happens enough to invalidate this approach. It sems to work for __extension__ so I am cautiously optimistic it'll work for __nowarn__. Still my preference is to go with the original union-hack and avoid this altogether. :-) --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu