| 637619b915888ead5576d19508644e4eb9024078 |
|
22-Feb-2013 |
John McCall <rjmccall@apple.com> |
Only suppress instance context if a member is actually
accessible in its declaring class; otherwise we might
fail to apply [class.protected] when considering
accessibility in derived classes.
Noticed by inspection; <rdar://13270329>.
I had an existing test wrong. Here's why it's wrong:
Follow the rules (and notation) of [class.access]p5.
The naming class (N) is B and the context (R) is D::getX.
- 'x' as a member of B is protected, but R does not occur
in a member or friend of a class derived from B.
- There does exist a base class of B, A, which is accessible
from R, and 'x' is accessible at R when named in A because
'x' as a member of A is protected and R occurs in a member
of a class, D, that is derived from A; however, by
[class.protected], the class of the object expression must
be equal to or derived from that class, and A does not
derive from D.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175858 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/class.access/class.protected/p1.cpp
|
| 8bddeb57d134c0e5f14e319271aa9015886a8ac7 |
|
25-Aug-2012 |
John McCall <rjmccall@apple.com> |
When computing the effective context for access control,
make sure we walk up the DC chain for the current context,
rather than allowing ourselves to get switched over to the
canonical DC chain. Fixes PR13642.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162616 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/class.access/class.protected/p1.cpp
|
| 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
|