From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5176 invoked by alias); 6 Oct 2002 03:20:02 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 5169 invoked from network); 6 Oct 2002 03:20:01 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 6 Oct 2002 03:20:01 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17y2tQ-0002bl-00 for ; Sat, 05 Oct 2002 23:19:49 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17y1y9-0007rE-00 for ; Sat, 05 Oct 2002 23:20:37 -0400 Date: Sat, 05 Oct 2002 20:20:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: New branch ``drow-cplus-branch'' Message-ID: <20021006032037.GA28685@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2002-10/txt/msg00059.txt.bz2 I've created a branch for the C++ and namespace improvements David and I were discussing. I've committed two patches to it, also, which I'll send along to gdb-patches in a moment. The name of the branch is ``drow-cplus-branch''. The policy for this branch is: 1. Committing things 1a. If you're me, hey, it's your branch. Commit things. Send a copy to the list. 1b. If you're someone else, hey, it's a development branch. Commit things. But first send them to gdb-patches (GCC has the convention of prefixing with [branchname], I recommend that) so that I can OK them. I'll probably OK them. I just want to keep tabs on what goes on the branch. 2. Recording things There's a file named ChangeLog.cplus on the branch. Write proper ChangeLog entres at all times. Put them in that file instead of the normal ChangeLog. This'll make merges simpler. Right now the testsuite results on the branch are probably dead in the water. I've added changes which we don't have all of the infrastructure for, because without them I can't work out what the right infrastructure is. It will get better in time, I promise. Mostly once I figure out how it should look! I'm considering a user setting for c-typeprint: auto, like the v2 demangler puts out, like the v3 demangler puts out, like we currently print. Once I finish the unit test harness I keep posting about I'll probably implement this, and write the necessary unit tests to make sure it all works. This will make testing much easier, because I can unit test the type printer in all four modes and then write C++ tests only in one of the constant modes. All the fuzziness with {\((void|)\)} and { ?&} can go away after that. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer