| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 112950
|
|
|
|
| |
llvm-svn: 112360
|
|
|
|
| |
llvm-svn: 112359
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 112358
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an '&' expression from the second caller of ActOnIdExpression.
Teach template argument deduction that an overloaded id-expression
doesn't give a valid type for deduction purposes to a non-static
member function unless the expression has the correct syntactic
form.
Teach ActOnIdExpression that it shouldn't try to create implicit
member expressions for '&function', because this isn't a
permitted form of use for member functions.
Teach CheckAddressOfOperand to diagnose these more carefully.
Some of these cases aren't reachable right now because earlier
diagnostics interrupt them.
llvm-svn: 112258
|
|
|
|
| |
llvm-svn: 112148
|
|
|
|
|
|
| |
header.", it is teh broken.
llvm-svn: 112123
|
|
|
|
|
|
|
|
| |
This works courtesy of the new SmallVector<..., 0> specialization that
doesn't require a complete type. Note that you'll need to pull at least
SmallVector.h from LLVM to compile successfully.
llvm-svn: 112114
|
|
|
|
|
|
|
| |
Clients of Sema don't need to know (for example) the list of diagnostics we
support.
llvm-svn: 112093
|
|
|
|
| |
llvm-svn: 111611
|
|
|
|
|
|
| |
Avoids a crash.
llvm-svn: 111609
|
|
|
|
| |
llvm-svn: 110945
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is more targeted, as it simply provides toggle actions for the parser to
turn access checking on and off. We then use these to suppress access checking
only while we parse the template-id (included scope specifier) of an explicit
instantiation and explicit specialization of a class template. The
specialization behavior is an extension, as it seems likely a defect that the
standard did not exempt them as it does explicit instantiations.
This allows the very common practice of specializing trait classes to work for
private, internal types. This doesn't address instantiating or specializing
function templates, although those apparently already partially work.
The naming and style for the Action layer isn't my favorite, comments and
suggestions would be appreciated there.
llvm-svn: 106993
|
|
|
|
|
|
| |
constructor into an extension warning into the error that C++98 requires.
llvm-svn: 105529
|
|
|
|
|
|
|
| |
along an access path, add another note pointing at the member we
actually found.
llvm-svn: 104937
|