| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
access to a private member to which we have special access.
rdar://12926092
llvm-svn: 176146
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 175858
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
| |
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164766
llvm-svn: 164769
|
|
|
|
| |
llvm-svn: 164766
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 162616
|
|
|
|
| |
llvm-svn: 162506
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
things going on here that were problematic:
- We were missing the actual access check, or rather, it was suppressed
on account of being a redeclaration lookup.
- The access check would naturally happen during delay, which isn't
appropriate in this case.
- We weren't actually emitting dependent diagnostics associated with
class templates, which was unfortunate.
- Access was being propagated incorrectly for friend method declarations
that couldn't be matched at parse-time.
llvm-svn: 161652
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This required moving the ctors for IntegerLiteral and FloatingLiteral out of
line which shouldn't change anything as they are usually called through Create
methods that are already out of line.
ASTContext::Deallocate has been a nop for a long time, drop it from ASTVector
and make it independent from ASTContext.h
Pass the StorageAllocator directly to AccessedEntity so it doesn't need to
have a definition of ASTContext around.
llvm-svn: 159718
|
|
|
|
| |
llvm-svn: 158981
|
|
|
|
|
|
|
|
|
|
| |
so that we actually accumulate all the delayed diagnostics. Do
this so that we can restore those diagnostics to good standing
if it turns out that we were wrong to suppress, e.g. if the
tag specifier is actually an elaborated type specifier and not
a declaration.
llvm-svn: 156291
|
|
|
|
| |
llvm-svn: 156290
|
|
|
|
| |
llvm-svn: 155107
|
|
|
|
|
|
| |
Follow up to r154924: check that we are in a static CMethodDecl to enable the Microsoft bug emulation regarding access to protected member during PTM creation. Not just any static function.
llvm-svn: 154982
|
|
|
|
|
|
|
|
| |
member of base class is allowed but only from a static function.
This fixes a regression when parsing MFC code with clang.
llvm-svn: 154924
|
|
|
|
|
|
|
|
| |
to define a special member function as deleted so that it properly
establishes an object context for the accesses to the base subobject
members.
llvm-svn: 154343
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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.
llvm-svn: 154248
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
|
|
| |
specialize location information and diagnostics for this entity.
llvm-svn: 150588
|
|
|
|
|
|
| |
Found by clang's own static analyzer.
llvm-svn: 148542
|
|
|
|
|
|
| |
appropriate or when GCC requires it)
llvm-svn: 148292
|
|
|
|
|
|
|
|
|
|
|
|
| |
we have a redeclarable type, and only use the new virtual versions
(getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have
that type information. This keeps us from penalizing users with strict
type information (and is the moral equivalent of a "final" method).
Plus, settle on the names getPreviousDecl() and getMostRecentDecl()
throughout.
llvm-svn: 148187
|
|
|
|
|
|
|
| |
'is an extension'. The former is inappropriate and confusing when building with
-Werror/-pedantic-errors.
llvm-svn: 147357
|
|
|
|
|
|
|
|
| |
to declaresSameEntity(), as a baby step toward tracking forward
declarations of Objective-C classes precisely. Part of
<rdar://problem/10583531>.
llvm-svn: 146618
|
|
|
|
|
|
| |
at the bases of an undefined class. Fixes <rdar://problem/10438657>.
llvm-svn: 144582
|
|
|
|
|
|
| |
accessibility. Fixes <rdar://problem/3727335>.
llvm-svn: 143635
|
|
|
|
| |
llvm-svn: 143618
|
|
|
|
|
|
| |
than a class
llvm-svn: 143615
|
|
|
|
|
|
| |
class member. Fixes PR11108.
llvm-svn: 141600
|
|
|
|
|
|
| |
context. Fixes PR9103.
llvm-svn: 141520
|
|
|
|
|
|
| |
available, but not accessible from the current code completion context.
llvm-svn: 141278
|
|
|
|
|
|
| |
conversions (rather than just call-arguments).
llvm-svn: 140244
|
|
|
|
|
|
| |
-fm-compatibility.
llvm-svn: 140189
|
|
|
|
| |
llvm-svn: 140017
|
|
|
|
|
|
|
|
| |
that this flag must be used only for Microsoft extensions and not emulation; to avoid confusion with the new LangOptions::MicrosoftMode flag.
Many of the code now under LangOptions::MicrosoftExt will eventually be moved under the LangOptions::MicrosoftMode flag.
llvm-svn: 139987
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
|
|
|
|
| |
isn't yet used for the less controlled environments of initialization.
Also a few random text fixups.
llvm-svn: 132833
|
|
|
|
| |
llvm-svn: 132096
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declaration found is unaccessible (private) and that declaration was bring into scope via another using declaration whose target declaration is accessible (public) then no error is generated.
Example:
class A { public: int f(); };
class B : public A { private: using A::f; };
class C : public B { private: using B::f; };
Here, B::f is private so this should fail in Standard C++, but because B::f refers to A::f which is public MSVC accepts it.
This fixes 1 error when parsing MFC code with clang.
llvm-svn: 131896
|
|
|
|
|
|
| |
constructor" again
llvm-svn: 131706
|
|
|
|
| |
llvm-svn: 131259
|
|
|
|
|
|
|
|
|
| |
I've edited one diagnostic which would print "copy constructor" for copy
constructors and "constructor" for any other constructor. If anyone is
extremely enamored with this, it can be reinstated with a simple boolean
flag rather than calling getSpecialMember, which is inappropriate.
llvm-svn: 131143
|
|
|
|
| |
llvm-svn: 130953
|
|
|
|
| |
llvm-svn: 129567
|
|
|
|
| |
llvm-svn: 125609
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
access-control diagnostics which arise from the portion of the declarator
following the scope specifier, just in case access is granted by
friending the individual method. This can also happen with in-line
member function declarations of class templates due to templated-scope
friend declarations.
We were really playing fast-and-loose before with this sort of thing,
and it turned out to work because *most* friend functions are in file
scope. Making us delay regardless of context exposed several bugs with
how we were manipulating delay. I ended up needing a concept of a
context that's independent of the declarations in which it appears,
and then I actually had to make some things save contexts correctly,
but delay should be much cleaner now.
I also encapsulated all the delayed-diagnostics machinery in a single
subobject of Sema; this is a pattern we might want to consider rolling
out to other components of Sema.
llvm-svn: 125485
|
|
|
|
| |
llvm-svn: 120266
|
|
|
|
|
|
| |
say 'implicitly' when it was implicit. Resolves PR 7930 and my peace of mind.
llvm-svn: 116916
|
|
|
|
|
|
|
|
| |
by marking the decl invalid isn't. Make some steps towards supporting these
and then hastily shut them down at the last second by marking them as
unsupported.
llvm-svn: 116661
|
|
|
|
|
|
|
|
| |
of templated-scope friends by marking them invalid and white-listing all
accesses until such time as we implement them. Fixes a crash, this time
without a broken test case.
llvm-svn: 116364
|