[cfe-dev] Is this a clang bug? "Foo::Foo::bar"

[Richard Smith]

On Tue, Jul 16, 2013 at 1:15 PM, Tomasz Mikolajczyk <tmmikolajczyk at gmail.com
> wrote:

> FYI, I submitted such issue some time ago:
> http://llvm.org/bugs/show_bug.cgi?id=14100
>
> It has been rejected as invalid at that time.
>

Oh, my bad, I should have looked at the example in this mail thread more
closely. PR14100 is invalid, and the original code in this thread is valid.


> Regards,
> Tomek
>
>
> On Tue, Jul 16, 2013 at 9:14 PM, Mehdi AMINI <mehdi.amini at silkan.com>wrote:
>
>> Hi,
>>
>> I tried to understand the PR15243 and I read the core issue 1310* but the
>> examples given in both the ticket and the description with resolution 1310
>> focus on the lookup of a class constructor and not a member function, like
>> the example given by Jonathan. How is it applicable here, it seems to me
>> that there is no ambiguity about the fact that "Foo" cannot be the
>> constructor in "Foo::Foo::bar"?
>>
>
You're right, in this case, Foo::Foo::bar is valid. But it's not a question
of ambiguity -- per DR1310, Foo::Foo names the constructor in all cases
except:
  * before "::",
  * after "struct", "class" or "union", or
  * in a class definition's base specifier list
... even if that makes the program ill-formed. This is the part that Clang
doesn't implement correctly (and is the subject of PR15243).

Thanks,
>>
>> Mehdi
>>
>> *http://www.open-std.org/jtc1/**sc22/wg21/docs/cwg_defects.**html<http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html>
>>
>> On 7/16/13 11:39 AM, Richard Smith wrote:
>>
>>> That's a bug: llvm.org/PR15243 <http://llvm.org/PR15243>
>>>
>>>
>>> The standard wording used to be ambiguous here, the resolution chosen by
>>> the committee didn't match clang's interpretation of the ambiguity, and
>>> no-one has gotten around to fixing it yet. Patches would be welcome ;-)
>>>
>>> On Tue, Jul 16, 2013 at 6:35 AM, Jonathan Sauer <jonathan.sauer at gmx.de
>>> <mailto:jonathan.sauer at gmx.de>**> wrote:
>>>
>>>     Hello,
>>>
>>>     the following program compiles with clang r186311, and I'm not sure
>>>     if this is a bug
>>>     or correct behavior:
>>>
>>>     struct Foo {
>>>          void bar();
>>>     };
>>>
>>>
>>>     void Foo::Foo::Foo::Foo::Foo::Foo::**bar()
>>>     {
>>>     }
>>>
>>>
>>>     According to §3.3.7p1 bullet 5 (basic.scope.class), the potential
>>>     scope of a class
>>>     includes "the regions defined by its member definitions [...]
>>>     including the member
>>>     function body and any portion of the declarator part of such
>>>     definitions which follows
>>>     the declarator-id", and §3.4.3.1p1 (class.qual) states that "A class
>>>     member can be
>>>     referred to using a qualified-id at any point in its potential
>>>     scope" while "the name
>>>     [specified after the nested-name-specifier] shall represent one or
>>>     more members of
>>>     that class or of one of its base classes."
>>>
>>>     However in the code above the member function "bar" is referred to
>>>     using a qualified-id
>>>     in its declarator-id, which is not part of the class' potential
>>>     scope, and "Foo" isn't
>>>     a base class of itself, so this shouldn't be allowed.
>>>
>>>     Still, I'm not sure if I got all the subtleties of C++'s name lookup
>>>     rules right, so
>>>     I'd like to make sure if this is a bug in clang or merely the
>>>     somewhat amusing result
>>>     of the way names in C++ can be specified.
>>>
>>>
>>>     With many thanks in advance,
>>>     Jonathan
>>>
>>>
>>>     ______________________________**_________________
>>>     cfe-dev mailing list
>>>     cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>>>     http://lists.cs.uiuc.edu/**mailman/listinfo/cfe-dev<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
>>>
>>>
>>>
>>>
>>>
>>> ______________________________**_________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/**mailman/listinfo/cfe-dev<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
>>>
>>>
>>
>> ______________________________**_________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/**mailman/listinfo/cfe-dev<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130716/9e19f6cc/attachment.html>