On Sun, Mar 10, 2013 at 5:02 PM, Stephen Lin <[email protected]> wrote: > 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.
Generally, yes. Details are here: http://llvm.org/docs/DeveloperPolicy.html > > Thanks, > Stephen > > On Sun, Mar 10, 2013 at 5:47 PM, Stephen Lin <[email protected]> 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 <[email protected]> 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 > _______________________________________________ > cfe-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
