[llvm-bugs] [Bug 31747] New: friend definition in nested class has private access to enclosing class

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Jan 24 15:13:48 PST 2017


https://llvm.org/bugs/show_bug.cgi?id=31747

            Bug ID: 31747
           Summary: friend definition in nested class has private access
                    to enclosing class
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: aurzenligl at gmail.com
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org
    Classification: Unclassified

Clang accepts ill-formed code in -std=c++11/14/1z:

struct Outer
{
    struct Inner
    {
        friend int get(Outer& o)
        {
            return o.x;
        }
    };
private:
    int x;
};

Legal basis (based on c++11 standard):
    7.3.1.2[3], 11.3[6]: in-class friend function definition
                         is a namespace member
    3.4.1[9], 11.3[7]: in-class friend function definition
                       has member function lexical scope
    11.7[1]: in-nested-class function definition
             can access private members of enclosing class
    9.7[4]: in-nested-class friend function definition
            has no special access rights to members of an enclosing class

It seems that explicit exception in 9.7[4] is not respected: "(...) friend
function (...) has no special access rights to members of an enclosing class".
There's no warning with -Wall -Wextra -pedantic on clang-3.5, newer and trunk.

I'd expect compilation to fail with error. Other compilers (gcc, msvc, icc)
fail as expected, noting that in given context x is private.

In c++98 code is ill-formed as well and clang incorrectly compiles it silently.
In c++98 access from nested to enclosing class privates is illegal (11.8[1]
c++03). In c++11 above clause was relaxed (11.7[1] c++11), but this shouldn't
change the meaning of -std=c++98/03 in clang.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170124/c8086288/attachment.html>


More information about the llvm-bugs mailing list