Jason Merrill writes:
> On 10/13/2011 01:12 PM, Dodji Seketeli wrote:
>> + while (true)
>> +{
>> + if (!linemap_macro_expansion_map_p (map0)
>> + || !linemap_macro_expansion_map_p (map1)
>> + || map0 == map1)
>> + break;
>
> I'd put the test in the condition, but i
On 10/13/2011 01:12 PM, Dodji Seketeli wrote:
+ while (true)
+{
+ if (!linemap_macro_expansion_map_p (map0)
+ || !linemap_macro_expansion_map_p (map1)
+ || map0 == map1)
+ break;
I'd put the test in the condition, but if you find it clearer this way,
I guess tha
On Tue, Oct 11, 2011 at 9:47 AM, Jason Merrill wrote:
> That looks pretty good, but do you really need to build up a separate data
> structure to search? You seem to be searching it in the same order that
> it's built up, so why not just walk the expansion chain directly when
> searching?
Agree
That looks pretty good, but do you really need to build up a separate
data structure to search? You seem to be searching it in the same order
that it's built up, so why not just walk the expansion chain directly
when searching?
Jason
Jason Merrill writes:
> I was thinking that you could walk the macro expansions to see if the
> two locations have an expansion in common, and if so compare the
> indices. I guess you could do this only if the locations have the same
> expansion location but are not themselves equal.
OK. I thou
I was thinking that you could walk the macro expansions to see if the two
locations have an expansion in common, and if so compare the indices. I guess
you could do this only if the locations have the same expansion location but
are not themselves equal.
If comparing the expansion locations is
Jason Merrill writes:
> On 10/03/2011 06:49 PM, Dodji Seketeli wrote:
>> Good question. Is the below better?
>
>> + if (linemap_location_from_macro_expansion_p (set, pre))
>> +pre = linemap_resolve_location (set, pre,
>> + LRK_MACRO_EXPANSION_POINT, NULL);
Jason Merrill writes:
> So then this change would make
>
> _Complex c;
>
> OK, but not
>
> static _Complex c;
>
> because the first declspec is not from a macro, right?
Yes.
>
>> I believe you noted this at some point and
>> agreed with me that ideally each declspec should come with its locatio
On 10/03/2011 04:08 PM, Dodji Seketeli wrote:
Jason Merrill writes:
-finish_declspecs (struct c_declspecs *specs)
+finish_declspecs (struct c_declspecs *specs,
+ location_t where)
I'm not sure the beginning of the declspecs is a better place for
these diagnostics than the begi
On 10/03/2011 06:49 PM, Dodji Seketeli wrote:
Good question. Is the below better?
+ if (linemap_location_from_macro_expansion_p (set, pre))
+pre = linemap_resolve_location (set, pre,
+ LRK_MACRO_EXPANSION_POINT, NULL);
+
+ if (linemap_location_from_macr
On 09/30/2011 11:28 AM, Jason Merrill wrote:
+linemap_location_before_p (struct line_maps *set,
+ source_location pre,
+ source_location post)
+{
+ bool pre_from_macro_p, post_from_macro_p;
+
+ if (pre == post)
+return false;
+
+ pre_from_
On 09/29/2011 05:21 PM, Dodji Seketeli wrote:
+ When the token is /not/ an argument for a macro, xI is the same
+ location as yI. Otherwise, xI is either the virtual location of
+ that argument token if it comes from a macro expansion itself, or
+ its spelling location.
I think
On 09/29/2011 01:19 PM, Dodji Seketeli wrote:
+ For a token that is /not/ an argument for a parameter of a
+ function-like macro, each yI is the spelling location of the Ith
+ token of the replacement-list in the definition of the macro.
+ "Spelling location" means the location of
On 09/27/2011 01:52 PM, Dodji Seketeli wrote:
+ Remember we are at the expansion point of MACRO. Each xI is the
+ location of the Ith token of the replacement-list. Now it gets
+ confusing. the xI is the location of the Ith token of the
+ replacement-list at the macro *definition
On 09/26/2011 04:21 PM, Dodji Seketeli wrote:
Jason Merrill writes:
On 09/21/2011 02:32 PM, Dodji Seketeli wrote:
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
Jason Merrill writes:
> On 09/21/2011 02:32 PM, Dodji Seketeli wrote:
>> 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.
>
> I disagree; arguments are t
On 09/21/2011 02:32 PM, Dodji Seketeli wrote:
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.
I disagree; arguments are the situation when the two locations
Jason Merrill 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_
On 09/20/2011 10:05 AM, Dodji Seketeli wrote:
Jason Merrill writes:
In linemap_macro_map_loc_to_def_point you get the token number and
then use that to index into MACRO_MAP_LOCATIONS. Can't you use the
same token number to index into macro->exp.tokens instead?
No, because a macro argument
Jason Merrill writes:
> On 09/20/2011 03:23 AM, Dodji Seketeli wrote:
>> Jason Merrill writes:
>
>>> Certainly all the calls to tokens_buff_add_token pass src->src_loc for
>>> the second. So why don't we look up the second location in the macro
>>> definition when we need it rather than store a
On 09/20/2011 03:23 AM, Dodji Seketeli wrote:
Jason Merrill writes:
Certainly all the calls to tokens_buff_add_token pass src->src_loc for
the second. So why don't we look up the second location in the macro
definition when we need it rather than store a copy in the map?
Because when you h
Jason Merrill writes:
> It is sounding to me like the first location (xI) gets you the next
> virtual location in the unwinding process, whereas the second location
> (yI) gets you the spelling location of the token in the definition of
> a macro.
Right.
> Certainly all the calls to tokens_buff
Jason Merrill writes:
> On 09/19/2011 09:58 AM, Dodji Seketeli wrote:
> > + The part that goes from the third to the heighth line of this
>
> An extra 'h' snuck in there. :)
Oops, fixed in my local copy, sorry.
>
> > Inside the definition of a macro M, you can have another macro M'.
> > And
On 09/19/2011 02:29 PM, Jason Merrill wrote:
expansion location. So it seems like we ought to be able to get away
with only storing one location per token in a macro expansion map. Am I
missing something?
I notice that here:
+/* Resolve the location iter->where into the locus 1/ of th
On 09/19/2011 09:58 AM, Dodji Seketeli wrote:
+ The part that goes from the third to the heighth line of this
An extra 'h' snuck in there. :)
Inside the definition of a macro M, you can have another macro M'.
And M' is going to be eventually expanded into a token FOO.
So, to paraphrase wha
Jason Merrill writes:
> On 09/16/2011 03:55 AM, Dodji Seketeli wrote:
> > +test.c: In function ‘g’:
> > +test.c:5:14: error: invalid operands to binary << (have ‘double’ and
> > ‘int’)
> > +test.c:2:9: note: in expansion of macro 'OPERATE'
> > +test.c:5:3: note: expanded from her
On 09/16/2011 03:55 AM, Dodji Seketeli wrote:
+test.c: In function ‘g’:
+test.c:5:14: error: invalid operands to binary << (have ‘double’ and ‘int’)
+test.c:2:9: note: in expansion of macro 'OPERATE'
+test.c:5:3: note: expanded from here
+test.c:5:14: note: in expansion of mac
> 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?
Oops, no. Removed and
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
Hello,
Below is an amended version of this patch after Jason's comments at
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00099.html.
From: Dodji Seketeli
Date: Sat, 4 Dec 2010 16:31:35 +0100
Subject: [PATCH 3/7] Emit macro expansion related diagnostics
In this third instalment the diagnostic mac
30 matches
Mail list logo
