[cfe-dev] WIP patch for qualified-ids in class member access

[Douglas Gregor]

On Jul 10, 2009, at 10:11 AM, James Porter wrote:

> Douglas Gregor wrote:
>> Since the conversion-function-id is the only place where I could  
>> imagine
>> your approach and my suggestion to differ, and in theory we have to  
>> do
>> *both*, let's go with your approach: it requires fewer changes, and  
>> we
>> can think about diagnosing paragraph 7 later.
>
> I've actually already changed to your original suggestion, since it
> cleans things up a bit so that I'm not rechecking the underlying types
> of the operations quite so often.

Oh, great! I was afraid that my original suggestion would have made it  
uglier. I'm happy with whatever is clean :)

> It's also possible that a different approach entirely will be  
> required,
> since in addition to paragraph 7, paragraph 6 also has some strange
> rules for name lookup:
>
> "If the nested-name-specifier contains a class template-id (14.2), its
> template-arguments are evaluated in the context in which the entire
> postfix-expression occurs."
>
> I'm almost certain that my patch will fail on this case, since it'll  
> be
> lookup up the template-arguments in the class's context as well. I  
> have
> a feeling that there's a solution that will handle both of these.

Ah, right. There's similar wording in [class.qual]p1 when parsing  
nested-name-specifiers (that aren't for class member access), but in  
that case we don't try to "enter" the context of the class/namespace  
in the nested-name-specifier, so we should get this right. Perhaps  
that's what we missed: maybe we need special name-lookup routines for  
the identifier that follows the -> (to deal with all of those weird  
semantics), rather than trying to enter a different context.

> Incidentally, I think it's possible to cause the same issue you
> mentioned about [basic.lookup.classref]p7 with *any* qualified-id  
> (p4).
> I'll see if I can write up a test that reveals this.

The tests for this probably need to make sure that the class type of  
the object expression is in a disjoint namespace from the postfix- 
expression itself, so that we don't accidentally find the right thing  
(e.g., up at global scope).

	- Doug