From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24271 invoked by alias); 27 May 2002 19:34:24 -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 24240 invoked from network); 27 May 2002 19:34:22 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by sources.redhat.com with SMTP; 27 May 2002 19:34:22 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id g4RJYKc28203; Mon, 27 May 2002 14:34:20 -0500 Date: Mon, 27 May 2002 13:09:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200205271934.g4RJYKc28203@duracef.shout.net> To: drow@mvista.com Subject: Re: [patch] testsuite/gdb.c++/local.exp: accept more nested types Cc: gdb-patches@sources.redhat.com X-SW-Source: 2002-05/txt/msg00950.txt.bz2 Hi Daniel, > I think that I (as C++ maintainer rather than testsuite maintainer) > need to figure out what the correct output is. Well, actually, the manual should specify the output of ptype, and you should implement the manual, and I should test to the manual. Without a written spec, we have to thrash this out among ourselves. > "InnerLocal::NestedInnerLocal nest1" is not actually valid C++ in > general, I don't believe; what if there is a class > InnerLocal::InnerLocal::NestedInnerLocal? Fortunately for us, that is not legal C++. gcc 2.96-rh and gcc 3.1 both give me a "duplicate nested type" error. I admit this is a technicality. But for purposes of human readability, it means that "InnerLocal::NestedInnerLocal nest1" will behave according to the expectations of a reasonable human reader. > This is also uglier; for std:: types there's going to be a lot of > useless noise. It's useful noise if the user has their own type with the same name as a std:: type. > By this logic, InnerLocal::NestedInnerLocal deserves a KFAIL comment > for the moment, since the code to do this is not yet present. I don't think it's a failure at all. Frankly, if we do decide it's a failure, I'd rather just leave it as a FAIL for a while. I don't want to add a bunch more regular expressions and file a bug report just to make it a different kind of failure. We're at an impasse here ... does anyone else have an opinion? Michael C