63f557804b76bf765aea58e5a46503e47e21f7c1 |
|
09-Apr-2012 |
John McCall <rjmccall@apple.com> |
My original patch missed the virtual-base case for destroying base-class subojects. Incidentally, thinking about virtual bases makes it clear to me that we're not appropriately computing the access to the virtual base's member because we're not computing the best possible access to the virtual base at all; in fact, we're basically assuming it's public. I'll file a separate PR about that. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154346 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/class.access/class.protected/p1.cpp
|
b9abd87283ac6e929b7e12a577663bc99e61d020 |
|
07-Apr-2012 |
John McCall <rjmccall@apple.com> |
Fix several problems with protected access control: - The [class.protected] restriction is non-trivial for any instance member, even if the access lacks an object (for example, if it's a pointer-to-member constant). In this case, it is equivalent to requiring the naming class to equal the context class. - The [class.protected] restriction applies to accesses to constructors and destructors. A protected constructor or destructor can only be used to create or destroy a base subobject, as a direct result. - Several places were dropping or misapplying object information. The standard could really be much clearer about what the object type is supposed to be in some of these accesses. Usually it's easy enough to find a reasonable answer, but still, the standard makes a very confident statement about accesses to instance members only being possible in either pointer-to-member literals or member access expressions, which just completely ignores concepts like constructor and destructor calls, using declarations, unevaluated field references, etc. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154248 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/class.access/class.protected/p1.cpp
|
ac57f0b9097e04f70a631549383a2944f74ad844 |
|
10-Oct-2011 |
Douglas Gregor <dgregor@apple.com> |
The effective context of a friend function is its lexical context. Fixes PR9103. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141520 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/class.access/class.protected/p1.cpp
|
fe24e05a87e48fa3318b65d1a92c542107639fd9 |
|
03-Sep-2010 |
John McCall <rjmccall@apple.com> |
Add a quick-and-dirty hack to give a better diagnostic for [class.protected] restrictions. The note's not really on the right place given its wording, but putting a second note on the call site (or muddying the wording) doesn't appeal. There are corner cases where this can be wrong, but I'm not concerned. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112950 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/class.access/class.protected/p1.cpp
|
326c8c7d6e6996c82a1da55c1c3cd6cb4b89a584 |
|
28-Aug-2010 |
John McCall <rjmccall@apple.com> |
That's not the right direction to compute notional accessibility in at all. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112360 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/class.access/class.protected/p1.cpp
|
8c77bcb072e7fd089f39fd7e079b6d767bf583fa |
|
28-Aug-2010 |
John McCall <rjmccall@apple.com> |
When checking access control for an instance member access on an object of type I, if the current access target is protected when named in a class N, consider the friends of the classes P where I <= P <= N and where a notional member of N would be non-forbidden in P. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112358 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/class.access/class.protected/p1.cpp
|
76ef658c703faf72c00f324fb9edc03169718e3e |
|
28-May-2010 |
Douglas Gregor <dgregor@apple.com> |
When we complain about a member being inaccessible due to a constraint along an access path, add another note pointing at the member we actually found. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104937 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/class.access/class.protected/p1.cpp
|
7002f4c03c2d0544f4e8bea8d3a5636519081e35 |
|
09-Apr-2010 |
John McCall <rjmccall@apple.com> |
Turn access control on by default in -cc1. Remove -faccess-control from -cc1; add -fno-access-control. Make the driver pass -fno-access-control by default. Update a bunch of tests to be correct under access control. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100880 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/class.access/class.protected/p1.cpp
|
161755a09898c95d21bfff33707da9ca41cd53c5 |
|
06-Apr-2010 |
John McCall <rjmccall@apple.com> |
Implement the protected access restriction ([class.protected]), which requires that protected members be used on objects of types which derive from the naming class of the lookup. My first N attempts at this were poorly-founded, largely because the standard is very badly worded here. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100562 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/class.access/class.protected/p1.cpp
|