On 10/10/2011 03:59 PM, Fabien Chêne wrote:
Sorry but I've failed to see why you called them callers of
lookup_field_1, could you elaborate ?
Hmm, I was assuming that the other functions would have gotten their
decls via lookup_field_1, but I suppose that isn't true for unqualified
lookup tha
Hi,
2011/9/26 Jason Merrill :
> On 09/25/2011 05:06 PM, Fabien Chêne wrote:
>>
>> + else if ((using_decl = strip_using_decl (member)) != member)
>
>> + /* If it is a using decl, use its underlying decl. */
>> + type_decl = strip_using_decl (type_decl);
>
>> - if (DECL_NAME (field) == name
On 09/25/2011 05:06 PM, Fabien Chêne wrote:
+ else if ((using_decl = strip_using_decl (member)) != member)
+ /* If it is a using decl, use its underlying decl. */
+ type_decl = strip_using_decl (type_decl);
- if (DECL_NAME (field) == name
+ if (DECL_NAME (decl) == name
Jason,
Please ignore the previous patch, where I have introduced an
unintentional modification for PR c++/30195 in search.c, here is a new
one, sorry about that.
--
Fabien
Index: gcc/testsuite/g++.old-deja/g++.other/using1.C
===
---
Hi,
> Indeed, I've removed the blank trailing lines, and some in the middle,
> not all though, I like it readable as well ;-)
Thanks!
Paolo
2011/9/25 Paolo Carlini :
> ... nitpicking, of course, but in the testcases you have many blank trailing
> lines (and also some gratuitus, imho, blank lines in the middle)
Indeed, I've removed the blank trailing lines, and some in the middle,
not all though, I like it readable as well ;-)
--
Fa
... nitpicking, of course, but in the testcases you have many blank trailing
lines (and also some gratuitus, imho, blank lines in the middle)
Paolo
I've updated the patch. I can't resist to tackle PR 25994 at the same
time. There was a diagnostic about conflicting using declarations in
add_method, which is no longer necessary and bogus in the case of PR
25994, so I just removed it. Duplicated using declarations are now
diagnosed in supplement_
2011/9/23 Jason Merrill :
> On 09/22/2011 05:11 PM, Fabien Chêne wrote:
>>
>> 2011/9/22 Jason Merrill:
>
>>> I don't, it just seemed strange to handle functions differently from
>>> other
>>> decls here. But when I look more closely I see that we're in
>>> lookup_field_1, which isn't interested in
On 09/22/2011 05:11 PM, Fabien Chêne wrote:
2011/9/22 Jason Merrill:
I don't, it just seemed strange to handle functions differently from other
decls here. But when I look more closely I see that we're in
lookup_field_1, which isn't interested in functions, so I guess we do want
to ignore fun
2011/9/22 Jason Merrill :
> On 09/22/2011 04:22 AM, Fabien Chêne wrote:
>>
>> I would have thought that we want to do something with OVERLOAD here,
>> in order to get rid of PR c++/30195 and c++/25994 (removing a wrong
>> diagnostic additionaly)... But those PRs are already fixed by this
>> patch w
On 09/22/2011 04:22 AM, Fabien Chêne wrote:
I would have thought that we want to do something with OVERLOAD here,
in order to get rid of PR c++/30195 and c++/25994 (removing a wrong
diagnostic additionaly)... But those PRs are already fixed by this
patch without doing anything with OVERLOAD. Cons
2011/9/21 Jason Merrill :
> On 09/21/2011 01:59 PM, Fabien Chêne wrote:
if (!DECL_DEPENDENT_P (field))
- continue;
+ {
+ tree using_decl = USING_DECL_DECLS (field);
+ if ((TREE_CODE (using_decl) == FIELD_DECL
+
On 09/21/2011 01:59 PM, Fabien Chêne wrote:
if (!DECL_DEPENDENT_P (field))
- continue;
+ {
+ tree using_decl = USING_DECL_DECLS (field);
+ if ((TREE_CODE (using_decl) == FIELD_DECL
+ || TREE_CODE (using_decl) == TYPE_DECL)
+&&
... with the ChangeLog
gcc/ChangeLog
2011-09-21 Fabien Chêne
PR c++/26256
* dbxout.c (dbxout_type_fields): Ignore using declarations.
gcc/testsuite/ChangeLog
2011-09-21 Fabien Chêne
PR c++/26256
* g++.dg/lookup/using23.C: New.
* g++.dg/lookup/usi
Hi,
2011/9/20 Jason Merrill :
> On 09/17/2011 09:44 AM, Fabien Chêne wrote:
>>
>> I tried various things without success, and I ended up hacking
>> supplement_binding_1 to handle those ENUMERAL_TYPEs.
>> I am all ear for another solution ...
>
> Your solution seems reasonable to me, but it needs a
On 09/17/2011 09:44 AM, Fabien Chêne wrote:
I tried various things without success, and I ended up hacking
supplement_binding_1 to handle those ENUMERAL_TYPEs.
I am all ear for another solution ...
Your solution seems reasonable to me, but it needs a comment, along the
lines of
/* We allow p
Hi!
(Again, sorry for the long delay, but I indeed have very few time to work on it)
2011/6/22 Jason Merrill :
> On 06/15/2011 01:58 PM, Fabien Chęne wrote:
>>
>> Otherwise, perhaps that it would be better if the second declaration
>> of E1 does not rely on supplement_binding_1.
>> What do you th
On 06/15/2011 01:58 PM, Fabien Chêne wrote:
Otherwise, perhaps that it would be better if the second declaration
of E1 does not rely on supplement_binding_1.
What do you think ?
I agree. We should be using xref_tag for this like we do with classes,
so we don't try to push the same tag more th
Hi,
After updating the patch, I now see a failure on c++0x forward enums.
Consider the below code:
template
struct S1
{
enum class E1;
enum class E1;
};
Currently, the second declaration of E1 relies on a successfull call
to supplement_binding_1.
With the patch I am working on, it no lo
2011/3/5 Jason Merrill :
> On 03/04/2011 03:11 AM, Fabien Chêne wrote:
>>
>> Hmm, I've implemented what you were suggesting, and I don't understand
>> the following check in supplement_binding:
>>
>> else if (TREE_CODE (bval) == TYPE_DECL&& DECL_ARTIFICIAL (bval))
>> {
>> /* The old bind
On 03/04/2011 03:11 AM, Fabien Chêne wrote:
Hmm, I've implemented what you were suggesting, and I don't understand
the following check in supplement_binding:
else if (TREE_CODE (bval) == TYPE_DECL&& DECL_ARTIFICIAL (bval))
{
/* The old binding was a type name. It was placed in
Hi,
Sorry for the looong delay,
2010/12/22 Jason Merrill :
> On 12/20/2010 07:02 AM, Fabien Chêne wrote:
>>
>> + {
>> + tree using_decl = USING_DECL_DECLS (field);
>> + if ((TREE_CODE (using_decl) == FIELD_DECL
>> + || TREE_CODE (using_decl) == T
23 matches
Mail list logo
