[cfe-commits] r154248 - in /cfe/trunk: include/clang/Basic/DiagnosticSemaKinds.td include/clang/Sema/Sema.h lib/Sema/SemaAccess.cpp lib/Sema/SemaDeclCXX.cpp lib/Sema/SemaExprCXX.cpp lib/Sema/SemaInit.cpp test/CXX/class.access/class.protected/p1.c

[Francois Pichet]

On Fri, Apr 6, 2012 at 11:04 PM, John McCall <rjmccall at apple.com> wrote:
> Author: rjmccall
> Date: Fri Apr  6 22:04:20 2012
> New Revision: 154248
>
> URL: http://llvm.org/viewvc/llvm-project?rev=154248&view=rev
> Log:
> 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.
>

Hi John,
I am not asking you to make the modification but do you have any
suggestion about how to handle case like that in MicrosoftMode?

class A {
protected:
	void f();
};

class B : public A{
public:
	void test();
};

void B::test() {
	&A::f;
}