From: Dodji Seketeli <dodji@redhat.com>
To: Jason Merrill <jason@redhat.com>
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
Date: Wed, 21 Sep 2011 19:09:00 -0000 [thread overview]
Message-ID: <m3y5xh21ca.fsf@redhat.com> (raw)
In-Reply-To: <4E793BF4.4010103@redhat.com> (Jason Merrill's message of "Tue, 20 Sep 2011 21:20:52 -0400")
Jason Merrill <jason@redhat.com> writes:
> My point was more that the name of the function is confusing;
Sorry about that.
> if what you get back is another virtual location, that's not what I
> would consider a "def point".
For tokens that are not function-like macro arguments, I think the
linemap_macro_loc_to_def_point makes sense because what we get then is
the source location in the actual definition of the macro. Actually I
think that's where the confusion comes from. I first devised the name
while thinking of the case of macros that are not function-like. And
now it falls short for the general case. I should have caught that
but for some reason I was just seeing through the name is if it was
transparent. Sigh.
I take your point; that name doesn't make sense in the general case.
> The only time you get a source location in the actual definition of
> the macro is when you ask for the "macro parm usage point".
Yes that, and in the case above; in which case xI and yI are equal, by
the way.
> When we start out, we have a virtual location that represents << in
> the expansion of OPERATE. Then we call
> linemap_macro_map_loc_to_def_point to get a virtual location that
> represents << in the expansion of SHIFTL. This is not part of the
> definition of OPERATE, and shouldn't be described as such.
Agreed.
> It seems that this function steps out until we hit the spelling
> location, and then we have a real source location and stop, which is
> why the loop in maybe_unwind_expanded_macro_loc needs to use
> linemap_macro_map_loc_to_exp_point as well. Right?
Right.
> It seems to me that we should encapsulate all of this in a function
> that expresses this unwinding operation, say
> "linemap_macro_map_loc_unwind_once". So the loop would look like
>
> + do
> + {
> + loc.where = where;
> + loc.map = map;
> +
> + VEC_safe_push (loc_t, heap, loc_vec, &loc);
> +
> + /* WHERE is the location of a token inside the expansion of a
> + macro. MAP is the map holding the locations of that macro
> + expansion. Let's get the location of the token in the
> + context that triggered the expansion of this macro.
> + This is basically how we go "down" in the trace of macro
> + expansions that led to WHERE. */
> + where = linemap_unwind_once (where, &map);
> + } while (linemap_macro_expansion_map_p (map));
>
OK.
> I think that linemap_macro_loc_to_def_point when called with false
> returns the unwound spelling location of the token (and thus is used
> for LRK_SPELLING_LOCATION),
Right.
> or when called with true returns the (not-unwound) location in the
> expanded macro (and so I think LRK_MACRO_PARM_REPLACEMENT_POINT
> should be renamed to LRK_MACRO_EXPANDED_LOCATION or something
> similar).
FWIW, I'd like the LRK_MACRO_PARM_REPLACEMENT name (or its
replacement. ha ha) to hint at the fact that it really has to do with
a token that is an /argument/ for a function-like macro. So maybe
LRK_MACRO_PARM_FOR_ARG_LOCATION? LRK_MACRO_EXPANDED_LOCATION really
seems too vague to me. After all, pretty much everything is about
*EXPAND*ing macros here. :-)
> It seems to me that either we should split those functions apart in
> to two functions with clearer names, or bundle them and
> linemap_macro_loc_to_exp_point into linemap_resolve_location; if
> linemap_location_in_system_header_p used linemap_resolve_location it
> would be more readable anyway.
OK.
> I'm having trouble thinking of a less misleading name for
> linemap_macro_map_loc_to_def_point, since the two locations serve
> completely different purposes. Maybe something vague like
> linemap_macro_map_loc_get_stored_loc. Or split it into two
> functions like linemap_virtual_loc_unwind_once_toward_spelling and
> linemap_virtual_loc_get_expanded_location or something like that.
So would a function named linemap_macro_map_loc_to_def_point that
returns the second location (yI) only, and a second function
linemap_macro_map_loc_unwind_once be less confusing to you? If yes,
then I'll send an updated patch for that in a short while.
Thanks.
--
Dodji
next prev parent reply other threads:[~2011-09-21 18:33 UTC|newest]
Thread overview: 142+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-10 11:27 [PATCH 0/6] Tracking locations of tokens resulting from macro expansion Dodji Seketeli
2010-12-10 11:16 ` [PATCH 4/6] Support -fdebug-cpp option Dodji Seketeli
2010-12-10 11:16 ` [PATCH 0/6] *** SUBJECT HERE *** Dodji Seketeli
2010-12-10 12:56 ` Dave Korn
2010-12-10 11:27 ` [PATCH 5/6] Add line map statistics to -fmem-report output Dodji Seketeli
2010-12-21 7:30 ` Gabriel Dos Reis
2011-04-13 20:08 ` Dodji Seketeli
2010-12-10 11:27 ` [PATCH 3/6] Emit macro expansion related diagnostics Dodji Seketeli
2010-12-13 15:25 ` Paolo Bonzini
2010-12-13 15:38 ` Paolo Bonzini
2010-12-13 16:30 ` Manuel López-Ibáñez
2010-12-14 7:24 ` Dodji Seketeli
2010-12-14 7:28 ` Gabriel Dos Reis
2010-12-14 8:40 ` Dodji Seketeli
2010-12-14 9:38 ` Gabriel Dos Reis
2010-12-14 9:42 ` Dodji Seketeli
2010-12-14 9:48 ` Gabriel Dos Reis
2010-12-14 7:28 ` Dodji Seketeli
2010-12-14 8:19 ` Gabriel Dos Reis
2010-12-14 8:31 ` Paolo Bonzini
2010-12-14 9:23 ` Dodji Seketeli
2010-12-10 11:53 ` [PATCH 1/6] Linemap infrastructure for virtual locations Dodji Seketeli
2011-01-06 16:48 ` Tom Tromey
2011-04-12 14:39 ` Dodji Seketeli
2011-04-14 14:46 ` Tom Tromey
2010-12-10 12:27 ` [PATCH 2/6] Generate virtual locations for tokens Dodji Seketeli
2010-12-10 12:33 ` [PATCH 6/6] Kill pedantic warnings on system headers macros Dodji Seketeli
2010-12-10 12:52 ` [PATCH 0/6] Tracking locations of tokens resulting from macro expansion Gabriel Dos Reis
2010-12-10 18:22 ` Dodji Seketeli
2010-12-10 16:59 ` Jeff Law
2010-12-10 19:00 ` Dodji Seketeli
2010-12-13 15:10 ` Jeff Law
2010-12-13 16:35 ` Gabriel Dos Reis
2010-12-14 9:24 ` Dodji Seketeli
2010-12-14 9:40 ` Gabriel Dos Reis
2010-12-14 9:45 ` Dodji Seketeli
2011-07-16 14:38 ` [PATCH 0/7] " Dodji Seketeli
[not found] ` <cover.1310824120.git.dodji@redhat.com>
2011-07-16 14:38 ` [PATCH 6/7] Kill pedantic warnings on system headers macros Dodji Seketeli
2011-09-12 22:09 ` Jason Merrill
2011-09-16 11:25 ` Dodji Seketeli
2011-09-17 22:34 ` Jason Merrill
2011-09-18 18:59 ` Dodji Seketeli
2011-07-16 14:38 ` [PATCH 3/7] Emit macro expansion related diagnostics Dodji Seketeli
2011-08-04 15:32 ` Dodji Seketeli
2011-09-12 21:54 ` Jason Merrill
2011-09-16 8:19 ` Dodji Seketeli
2011-09-17 21:27 ` Jason Merrill
2011-09-19 14:37 ` Dodji Seketeli
2011-09-19 19:47 ` Jason Merrill
2011-09-19 21:27 ` Jason Merrill
2011-09-20 8:47 ` Dodji Seketeli
2011-09-20 14:12 ` Jason Merrill
2011-09-20 14:12 ` Dodji Seketeli
2011-09-21 2:51 ` Jason Merrill
2011-09-21 19:09 ` Dodji Seketeli [this message]
2011-09-22 15:32 ` Jason Merrill
2011-09-26 21:11 ` Dodji Seketeli
2011-09-26 22:30 ` Jason Merrill
2011-09-27 18:43 ` Dodji Seketeli
2011-09-29 7:05 ` Jason Merrill
2011-09-29 19:20 ` Dodji Seketeli
2011-09-29 21:25 ` Jason Merrill
2011-09-29 23:33 ` Dodji Seketeli
2011-09-30 15:56 ` Jason Merrill
2011-09-30 21:04 ` Jason Merrill
2011-10-03 22:50 ` Dodji Seketeli
2011-10-04 19:59 ` Jason Merrill
2011-10-04 20:35 ` Dodji Seketeli
2011-10-03 20:09 ` Dodji Seketeli
2011-10-04 20:03 ` Jason Merrill
2011-10-04 20:28 ` Dodji Seketeli
2011-09-20 0:08 ` Dodji Seketeli
2011-07-16 14:39 ` [PATCH 5/7] Add line map statistics to -fmem-report output Dodji Seketeli
2011-09-12 22:07 ` Jason Merrill
2011-09-16 8:29 ` Dodji Seketeli
2011-09-17 22:05 ` Jason Merrill
2011-09-20 12:10 ` Dodji Seketeli
2011-09-20 14:08 ` Jason Merrill
2011-07-16 14:39 ` [PATCH 4/7] Support -fdebug-cpp option Dodji Seketeli
2011-08-21 11:02 ` Alexandre Oliva
2011-08-21 11:40 ` Jakub Jelinek
2011-08-22 14:45 ` Tom Tromey
2011-08-22 15:22 ` Jakub Jelinek
2011-08-23 19:52 ` Dodji Seketeli
2011-08-24 15:11 ` Tom Tromey
2011-09-12 22:07 ` Jason Merrill
2011-09-16 8:23 ` Dodji Seketeli
2011-09-17 22:01 ` Jason Merrill
2011-07-16 15:25 ` [PATCH 2/7] Generate virtual locations for tokens Dodji Seketeli
2011-08-09 15:30 ` Dodji Seketeli
2011-09-12 21:15 ` Jason Merrill
2011-09-14 10:01 ` Dodji Seketeli
2011-09-14 22:56 ` Jason Merrill
2011-09-18 13:44 ` Dodji Seketeli
2011-09-19 22:31 ` Jason Merrill
2011-09-21 14:55 ` Dodji Seketeli
2011-09-22 17:10 ` Jason Merrill
2011-09-26 14:47 ` Dodji Seketeli
2011-09-26 20:39 ` Jason Merrill
2011-09-28 3:23 ` Dodji Seketeli
2011-09-28 14:49 ` Jason Merrill
2011-09-28 21:24 ` Dodji Seketeli
2011-09-28 21:45 ` Jason Merrill
2011-09-29 5:49 ` Dodji Seketeli
2011-07-16 15:28 ` [PATCH 1/7] Linemap infrastructure for virtual locations Dodji Seketeli
2011-07-18 22:06 ` Jason Merrill
2011-07-19 10:47 ` Dodji Seketeli
2011-07-19 17:26 ` Jason Merrill
2011-07-19 18:03 ` Dodji Seketeli
2011-07-19 23:37 ` Jason Merrill
2011-07-30 6:20 ` Jason Merrill
2011-08-01 18:54 ` Dodji Seketeli
2011-08-01 4:42 ` Jason Merrill
2011-08-02 4:48 ` Jason Merrill
2011-08-04 15:28 ` Dodji Seketeli
2011-08-04 21:30 ` Jason Merrill
2011-08-05 17:12 ` Dodji Seketeli
2011-08-05 17:31 ` Jason Merrill
2011-08-09 14:56 ` Dodji Seketeli
2011-08-19 8:46 ` Jason Merrill
2011-08-19 14:43 ` Tom Tromey
2011-09-01 10:37 ` Dodji Seketeli
2011-09-07 19:26 ` Jason Merrill
2011-09-08 12:41 ` Dodji Seketeli
2011-09-09 7:45 ` Jason Merrill
2011-09-09 8:57 ` Jason Merrill
2011-07-16 15:34 ` [PATCH 7/7] Reduce memory waste due to non-power-of-2 allocs Dodji Seketeli
2011-09-12 22:25 ` Jason Merrill
2011-09-17 13:41 ` Dodji Seketeli
2011-09-17 22:22 ` Jason Merrill
2011-09-18 22:30 ` Dodji Seketeli
2011-09-19 6:51 ` Laurynas Biveinis
2011-07-16 16:47 ` [PATCH 0/7] Tracking locations of tokens resulting from macro expansion Tobias Burnus
2011-07-16 17:57 ` Dodji Seketeli
2011-10-04 21:07 [PATCH 3/7] Emit macro expansion related diagnostics Jason Merrill
2011-10-04 21:31 ` Dodji Seketeli
2011-10-11 9:09 ` Dodji Seketeli
2011-10-11 15:15 ` Jason Merrill
2011-10-12 17:44 ` Gabriel Dos Reis
2011-10-13 17:32 ` Dodji Seketeli
2011-10-14 22:21 ` Jason Merrill
2011-10-17 9:57 ` Dodji Seketeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3y5xh21ca.fsf@redhat.com \
--to=dodji@redhat.com \
--cc=bonzini@gnu.org \
--cc=burnus@net-b.de \
--cc=charlet@act-europe.fr \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdr@integrable-solutions.net \
--cc=jason@redhat.com \
--cc=joseph@codesourcery.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).