From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13993 invoked by alias); 12 Sep 2011 21:05:43 -0000 Received: (qmail 13980 invoked by uid 22791); 12 Sep 2011 21:05:41 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 12 Sep 2011 21:05:26 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8CL51pP005574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Sep 2011 17:05:01 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8CL50LT019513; Mon, 12 Sep 2011 17:05:00 -0400 Received: from [0.0.0.0] (ovpn-113-157.phx2.redhat.com [10.3.113.157]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p8CL4vXD027786; Mon, 12 Sep 2011 17:04:57 -0400 Message-ID: <4E6E73F8.4030603@redhat.com> Date: Mon, 12 Sep 2011 21:54:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Dodji Seketeli CC: gcc-patches@gcc.gnu.org, tromey@redhat.com, gdr@integrable-solutions.net, joseph@codesourcery.com, burnus@net-b.de, charlet@act-europe.fr, bonzini@gnu.org Subject: Re: [PATCH 3/7] Emit macro expansion related diagnostics References: <1291979498-1604-1-git-send-email-dodji@redhat.com> <7ab852c58faea9efd81130c5a1ddc9e78b34bcc5.1310824121.git.dodji@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: 2011-09/txt/msg00748.txt.bz2 On 08/04/2011 11:32 AM, Dodji Seketeli wrote: > +++ b/gcc/diagnostic.c > @@ -30,6 +30,7 @@ along with GCC; see the file COPYING3. If not see > #include "input.h" > #include "intl.h" > #include "diagnostic.h" > +#include "vec.h" Do you still need this? > // Just discard errors pointing at header files > // { dg-prune-output "include" } > +// { dg-prune-output " from" } These should be pruned by testsuite/lib/prune.exp. I'm surprised they aren't already. > +#define APPEND_LOC_TO_VEC(LOC) \ > + if (num_locs >=3D loc_vec_capacity) \ > + { \ > + loc_vec_capacity +=3D 4; \ > + loc_vec =3D XRESIZEVEC (loc_t, loc_vec, loc_vec_capacity); > \ > + } \ > + loc_vec[num_locs++] =3D LOC; Why not use VEC since we're in gcc/ here? > +/* Unwind the different macro expansions that lead to the token which > + location is WHERE and emit diagnostics showing the resulting > + unwound macro expansion stack. If TOPMOST_EXP_POINT_MAP is > + non-null, *TOPMOST_EXP_POINT_MAP is set to the map of the expansion > + point of the top most macro of the stack. This must be an ordinary > + map. */ I find the use of "top" here confusing. You mean the place in the source that first triggered the macro expansion, right? Can we avoid talking about stacks here? > + /* Walk the map_vec and print the macro expansion stack, unless the > + topmost macro which expansion triggered this stack [assuming the > + stack grows downwards] was expanded inside a system header. */ Abstract stacks are said to grow upwards; only the representation of a call stack on certain architectures can grow downwards. The top of the stack is the most recently pushed element, which in the case of macro expansion would be the innermost macro expanded. > + while (unwind) > + { ... > + if (!linemap_macro_expansion_map_p (map)) > + unwind =3D false; > + } This seems like a job for do/while. > + diagnostic->location =3D resolved_def_loc; > + pp_base_set_prefix (context->printer, > + diagnostic_build_prefix (context, > + diagnostic)); Using pp_verbatim like in maybe_print_constexpr_context seems simpler to me, but if you prefer this approach that's fine. Jason