From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33043 invoked by alias); 14 Sep 2015 19:42:53 -0000 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 Received: (qmail 33033 invoked by uid 89); 14 Sep 2015 19:42:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 14 Sep 2015 19:42:52 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 463CEA303F for ; Mon, 14 Sep 2015 19:42:51 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-28.phx2.redhat.com [10.3.113.28]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJgotG001785; Mon, 14 Sep 2015 15:42:50 -0400 Subject: Re: [PATCH 00/22] RFC: Overhaul of diagnostics To: Bernd Schmidt , David Malcolm , gcc-patches@gcc.gnu.org References: <1441916913-11547-1-git-send-email-dmalcolm@redhat.com> <55F7073E.8000308@redhat.com> From: Jeff Law Message-ID: <55F7233A.3010603@redhat.com> Date: Mon, 14 Sep 2015 19:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F7073E.8000308@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00976.txt.bz2 On 09/14/2015 11:43 AM, Bernd Schmidt wrote: > It's hard to provide meaningful review under these conditions. My advice > would be to resubmit the things that are ready now and can stand on > their own so that we can get them out of the way first. Also, gather > memory/time information before posting the patches if that seems likely > to be important. For example, patch 21 looks quite cool but also > potentially expensive, I'd probably want that to be restricted by param > to identifiers of a maximum length (for both identifiers being compared). I think David is looking for some feedback on some of this stuff. There's clearly some design/implementation issues in those middling patches. The thought behind showing the later patches is so that folks can generally see where this work is trying to go. One of my big worries is the memory consumption. > > For the most part I declare myself agnostic as to whether this is an > improvement or not, and leave that for others to comment on. I > personally prefer single-line errors without much noise. I wasn't a fan of rich location diagnostics, carets, etc. However, now that I'm doing more C++ bits, I'm seeing the utility of this kind of stuff. > > I see lots of unit tests implemented as plugins - have we decided that > this is the mechanism we want to use for this kind of thing? A lot of the plugin-based testing is stuff that's painful to test end-to-end. Probably the best way to think of those tests is they're trying to directly test internal state. Jeff