[cfe-commits] [PATCH] Report error on non-public friend access

John McCall rjmccall at apple.com
Wed Mar 7 22:40:52 PST 2012

On Feb 29, 2012, at 9:51 PM, Aaron Ballman wrote:
> This is a patch to address PR12126, where clang fails to diagnose
> friend declarations to private or protected member functions.

This check will only fire when the lookup and matching are non-dependent.
You'll need to add similar logic to the template-instantiation path in

+    for (LookupResult::iterator iter = Previous.begin(), end = Previous.end();
+          iter != end; ++iter) {

This should only check access to the function actually being friended.
The others should not be considered named.

+      if (Owner && Access != AS_public) {

The procedure for deciding whether something is accessible in a context
is way more complicated than this.  You're ignoring friendship,
containment within the declaring class, and (for protected members)
subclassing.  This is why all the code in SemaAccess.cpp exists.

CheckDirectMemberAccess should work, since the constraints on the
lookup mean that the access from the lookup has to equal the member's
access specifier.  (That's worth an assertion, though.)

Please add test cases for the cases where the friended method is
accessible due to friendship, containment, and subclassing.

Please also test that we're checking access to names from the scope
specifier.  For example, I believe the following code should be invalid
because Outer::Inner is not accessible within Test:
  class Outer { class Inner { public: void foo(); }; };
  class Test {
    friend void Outer::Inner::foo();


More information about the cfe-commits mailing list