aboutsummaryrefslogtreecommitdiff
path: root/test/CXX/class.access/class.protected
AgeCommit message (Collapse)Author
2013-02-22Only suppress instance context if a member is actuallyJohn McCall
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
2012-10-19Prior to adding the new "expected-no-diagnostics" directive to ↵Andy Gibbs
VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166280 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-24When computing the effective context for access control,John McCall
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
2012-04-09My original patch missed the virtual-base case for destroyingJohn McCall
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
2012-04-09Fix the access check performed as part of the determination of whetherJohn McCall
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
2012-04-07Fix several problems with protected access control:John McCall
- 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
2011-10-09The effective context of a friend function is its lexicalDouglas Gregor
context. Fixes PR9103. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141520 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-03Add a quick-and-dirty hack to give a better diagnostic for [class.protected]John McCall
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
2010-08-28That's not the right direction to compute notional accessibility in at all.John McCall
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112360 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-28When checking access control for an instance member access onJohn McCall
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
2010-05-28When we complain about a member being inaccessible due to a constraintDouglas Gregor
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
2010-04-09Turn access control on by default in -cc1.John McCall
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
2010-04-06Implement the protected access restriction ([class.protected]), which requiresJohn McCall
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