From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12722 invoked by alias); 30 Mar 2004 09:24:31 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12676 invoked from network); 30 Mar 2004 09:24:21 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 30 Mar 2004 09:24:21 -0000 Received: from localhost (localhost [127.0.0.1]) by nile.gnat.com (Postfix) with ESMTP id 02B4BF281A for ; Tue, 30 Mar 2004 04:24:14 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10978-02-3 for ; Tue, 30 Mar 2004 04:24:14 -0500 (EST) Received: by nile.gnat.com (Postfix, from userid 1345) id 2E716F281D; Tue, 30 Mar 2004 04:24:13 -0500 (EST) From: Paul Hilfinger To: gdb-patches@sources.redhat.com Subject: Re: [RFA] Add language-dependent post-parser Message-Id: <20040330092413.2E716F281D@nile.gnat.com> Date: Tue, 30 Mar 2004 09:24:00 -0000 X-Virus-Scanned: by amavisd-new at nile.gnat.com X-SW-Source: 2004-03/txt/msg00742.txt.bz2 Ping. I have not yet received a reply to my last message on this proposed patch (submitted Thu, 4 Mar 2004 06:33:45 -0500 (EST), with a followup message on Fri, 5 Mar 2004 03:15:26 -0500 (EST)). As a reminder, I've appended the discussion preceding the original patch and my response to Daniel. Paul Hilfinger Original message of 4 March (minus patch): For Ada, we found it convenient to do a name-resolution pass after parsing and before evaluation of expressions. The most convenient form on which to perform this resolution is the prefix form (that way, we can use the usual type-computing machinery already included in expression evaluation). Unfortunately, prefixification occurs after and separate from parsing. The obvious thing to do was to add a function to the language vector for post-parsing. For most languages, it does nothing. The patch below does most of the work in inserting this hook, including the introduction of a parse-in-type-context function that provides a type context for the post-parser. In its current form, this patch is a NOP that merely provides the hooks. Paul Hilfinger 2004-03-04 Paul N. Hilfinger * language.h (language_defn): Add new la_post_parser field. * parser-defs.h (null_post_parser): New declaration (default for la_post_parser). * parse.c (parse_exp_1): Move code to parse_exp_in_context and insert call to that function. (parse_exp_in_context): New function, including code formerly in parse_exp_1. Calls language-dependent post-parser after prefixification. (parse_expression_in_context): New exported function. (null_post_parser): New definition. * expression.h (parse_expression_in_context): Add declaration. * p-lang.c (pascal_language_defn): Add trivial post-parser. * c-lang.c (c_language_defn): Ditto. (cplus_language_defn): Ditto. (asm_language_defn): Ditto. (minimal_language_defn): Ditto. * f-lang.c (f_language_defn): Ditto. * jv-lang.c (java_language_defn): Ditto. * language.c (unknown_language_defn): Ditto. (auto_language_defn): Ditto. (local_language_defn): Ditto. * m2-lang.c (m2_language_defn): Ditto. * scm-lang.c (scm_language_defn): Ditto. * obj-lang.c (objc_language_defn): Ditto. ------------------------------------------------------------ My reply to Daniel Jacobowitz of 5 March: > Could you explain more about why you found this necessary? It's hard > to evaluate the patch without that. Daniel, Sure. In Ada mode, we handle overloaded functions (not just those that are the Ada equivalent of member functions). More precisely, we resolve overloading that can be resolved bottom-up, as C++ (almost always) does. The issue we encountered was the point at which GDB discovers it cannot resolve the overloading. With a command such as print f(3) there is no problem: you can resolve during execution, and print an error message (or whatever) then. But what about cond 1 (f(3) > 12) ? In similar C++ examples, such as cond 1 (A.f(3) > 12) you'll find that resolution problems are reported when the breakpoint is hit, possibly long after the breakpoint is set. This is safe (the program stops), but we felt it was somewhat annoying that one didn't notice the problem earlier. We perform resolution in the obvious way, but that calls for determining the static types of the arguments. While it is possible to do so during parsing, it would mean partially rebuilding the existing infrastructure that allows GDB to compute types and expression values. We thought it would be easier to operate on the same prefix form that is used for evaluation. Unfortunately, this happens only AFTER the language-dependent parser returns. Paul Hilfinger Ada Core Technologies, Inc.