[cfe-dev] Unreachable at IdentifierResolver.cpp:78 when friend-ing a using declaration

[Stephen Lin]

I updated the patch to check specifically for friend decls, rather
than basing the check on semantic scope (didn't realize that using
decls also belonged to the semantic scope of their original class;
build environment was in a different state than what I thought when I
ran the tests originally so didn't catch it)...all tests passed now
(including the new one to test this particular issue).

I just realized there's a separate cfe-commits list: should I submit
the patch there? Sorry for my unfamiliarity with procedures.

Thanks,
Stephen

On Sun, Mar 10, 2013 at 5:47 PM, Stephen Lin <stephenwlin at gmail.com> wrote:
> Apologies, not sure why I didn't notice before but the patch I
> attached seems to break a test (namespace.udecl/p12.cpp), so ignore
> it.
>
> On Sun, Mar 10, 2013 at 5:18 PM, Stephen Lin <stephenwlin at gmail.com> wrote:
>> Hi,
>>
>> I'm new to clang development but I think I've managed to find
>> and patch a small issue. I'm not sure what SOP is for this is, so I'm
>> sending a message here; if this is unnecessary in the future let me
>> know.
>>
>> The code below crashes because Sema::CheckOverload assumes that a
>> function declaration is in the same semantic scope as the current
>> lexical scope whenever the latter is a record and tries to use member
>> using hiding rules:
>>
>> struct A
>> {
>>     void delete_foo();
>> };
>>
>> struct B : public A
>> {
>>     using A::delete_foo;
>> };
>>
>> struct Foo { friend void B::delete_foo(); private: ~Foo() { } };
>>
>> Similar results are obtained when "friend"-ing a using declaration
>> declared at namespace scope.
>>
>> I added a small check to verify that the new function declaration is
>> actually in the same semantic scope as the current (record) scope: as
>> far as I can tell this can only affect "friend" declarations. The code
>> above now triggers an error "declaration conflicts with target of
>> using declaration already in scope" (I believe this is correct, g++
>> errors as well) rather than a crash, and added a test for this case.
>>
>> Bug report at http://llvm.org/bugs/show_bug.cgi?id=15485 with patch attached.
>>
>> Let me know if there's anything else I can do to help with this issue.
>>
>> Thanks,
>> Stephen