| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
When we check access for lookup results, make sure we propagate the
result's access to the access control APIs; this can be different from
the natural access of the declaration depending on the path used by the lookup.
PR17394.
llvm-svn: 191726
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike with namespaces, searching inside of classes requires also
checking the access to correction candidates (i.e. don't suggest a
correction to a private class member for a correction occurring outside
that class and its methods or friends).
Included is a small (one line) fix for a bug, that was uncovered while
cleaning up the unit tests, where the decls from a TypoCorrection candidate
were preserved in new TypoCorrection candidates that are derived (copied)
from the old TypoCorrection--notably when creating a new candidate by
changing the NestedNameSpecifier associated with the base idenitifer.
llvm-svn: 191449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variable from being the function to being the enclosing namespace scope (in
C++) or the TU (in C). This allows us to fix a selection of related issues
where we would build incorrect redeclaration chains for such declarations, and
fail to notice type mismatches.
Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern,
which is only found when searching scopes, and not found when searching
DeclContexts. Such a declaration is only made visible in its DeclContext if
there are no non-LocalExtern declarations.
llvm-svn: 191064
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 189112
|
|
|
|
| |
llvm-svn: 186647
|
|
|
|
| |
llvm-svn: 181332
|
|
|
|
|
|
| |
performed within the context of that class template. Patch by Ismail Pazarbasi!
llvm-svn: 180707
|
|
|
|
|
|
|
|
| |
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
|