| 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
1.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
1.cpp
|
| 12d8d80fb0f8d9cddecb34da0f37b0dc9fcaf5e6 |
09-Apr-2012 |
John McCall <rjmccall@apple.com> |
Fix the access check performed as part of the determination of whether
to define a special member function as deleted so that it properly
establishes an object context for the accesses to the base subobject
members.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154343 91177308-0d34-0410-b5e6-96231b3b80d8
1-cxx11.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.cpp
|