| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
to a cc1 -fencode-extended-block-signature and pass it
to cc1 and recognize this option to produce extended block
type signature. // rdar://12109031
llvm-svn: 168063
|
| |
|
|
|
|
| |
current list of powerpc-darwin8 failures.
llvm-svn: 168016
|
| |
|
|
|
|
|
|
| |
generate expanded signature encoding to include types as we
already do this for protocol method lists.
// rdar://12109031
llvm-svn: 167997
|
| |
|
|
|
|
| |
variables captured in a block. // rdar://12184410
llvm-svn: 167931
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This corrects the mangling and linkage of classes (& their member functions) in
cases like this:
struct foo {
struct {
void func() { ... }
} x;
};
we were accidentally giving this nested unnamed struct 'no' linkage where it
should've had the linkage of the outer class. The mangling was incorrecty too,
mangling as TU-wide unnamed type mangling of $_X rather than class-scoped
mangling of UtX_.
This also fixes -Wunused-member-function which would incorrectly diagnose
'func' as unused due to it having no linkage & thus appearing to be TU-local
when in fact it might be correctly used in another TU.
Similar mangling should be applied to function local classes in similar cases
but I've deferred that for a subsequent patch.
Review/discussion by Richard Smith, John McCall, & especially Eli Friedman.
llvm-svn: 167906
|
| |
|
|
|
|
|
| |
internal linkage, no uses, trivial construction, and nontrivial destruction
were not emitted.
llvm-svn: 167756
|
| |
|
|
| |
llvm-svn: 167357
|
| |
|
|
|
|
|
| |
has none of its own. Factor in Doug's comments.
// rdar://12378793
llvm-svn: 165771
|
| |
|
|
|
|
|
|
|
|
| |
methods looking for documentation on a particular base
class inherited by any method that overrides the base class.
In case of redeclaration, as when objc method is defined
in the implementation, it also looks up for documentation
in class/class extension being redeclared.
llvm-svn: 165643
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
AAPCS ABI Section 7.1.4 [1] specifies that va_list
should be defined as struct __va_list { void *__ap;};
And in C++, it is defined in namespace std.
[1] http://infocenter.arm.com/help/topic
/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
Patch by Weiming Zhao.
llvm-svn: 165609
|
| |
|
|
| |
llvm-svn: 165538
|
| |
|
|
|
|
|
|
| |
ASTContext to the ObjCMethodDecl, and have the more generic
ASTContext::getOverriddenMethods() use the ObjCMethodDecl::getOverriddenMethods()
function.
llvm-svn: 165518
|
| |
|
|
|
|
| |
ASTContext so that it can be widely available.
llvm-svn: 165473
|
| |
|
|
|
|
| |
canonical method; avoid storing them again for an out-of-line definition.
llvm-svn: 165472
|
| |
|
|
|
|
|
| |
use it to suggest appropriate macro for __attribute__((deprecated)) in
-Wdocumentation-deprecated-sync.
llvm-svn: 164892
|
| |
|
|
|
|
|
|
|
|
|
|
| |
enough information so we can mangle them correctly in cases involving
dependent parameter types. (This specifically impacts cases involving
null pointers and cases involving parameters of reference type.)
Fix the mangler to use this information instead of trying to scavenge
it out of the parameter declaration.
<rdar://problem/12296776>.
llvm-svn: 164656
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we have a list of all commands. This is a good thing in itself, but it
also enables us to easily implement typo correction for command names.
With this change we have objects that contain information about each command,
so it makes sense to resolve command name just once during lexing (currently we
store command names as strings and do a linear search every time some property
value is needed). Thus comment token and AST nodes were changed to contain a
command ID -- index into a tables of builtin and registered commands. Unknown
commands are registered during parsing and thus are also uniformly assigned an
ID. Using an ID instead of a StringRef is also a nice memory optimization
since ID is a small integer that fits into a common bitfield in Comment class.
This change implies that to get any information about a command (even a command
name) we need a CommandTraits object to resolve the command ID to CommandInfo*.
Currently a fresh temporary CommandTraits object is created whenever it is
needed since it does not have any state. But with this change it has state --
new commands can be registered, so a CommandTraits object was added to
ASTContext.
Also, in libclang CXComment has to be expanded to include a CXTranslationUnit
so that all functions working on comment AST nodes can get a CommandTraits
object. This breaks binary compatibility of CXComment APIs.
Now clang_FullComment_getAsXML(CXTranslationUnit TU, CXComment CXC) doesn't
need TU parameter anymore, so it was removed. This is a source-incompatible
change for this C API.
llvm-svn: 163540
|
| |
|
|
| |
llvm-svn: 163477
|
| |
|
|
| |
llvm-svn: 163476
|
| |
|
|
|
|
|
|
|
| |
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
llvm-svn: 162962
|
| |
|
|
|
|
|
|
|
|
|
| |
__objc_yes/__objc_no to (BOOL)1/(BOOL)0 when
BOOL is declared; otherwise it resorts to
default of 'signed char'. This is important to
selecting the correct Numeric API numberWithBool:
Can't have a clang test for this. Will checkin and
executable llvm test. // rdar://12156616
llvm-svn: 162922
|
| |
|
|
| |
llvm-svn: 162886
|
| |
|
|
| |
llvm-svn: 162730
|
| |
|
|
|
|
|
|
|
|
|
|
| |
not be set for implicit instantiations, remove the FIXME. This should be the
last bit for PR13634. The actual fix happened in r162238.
Motivation: it might be misleading to mark implicit instantiations as
Decl::isImplicit = true. Because then, in order to be consistent, we should
mark all instantiated members as implicit. But the user did actually type the
declaration for the member, but the compiler played with it a little bit.
llvm-svn: 162488
|
| |
|
|
| |
llvm-svn: 162374
|
| |
|
|
|
|
| |
implicit instantiation, look for documentation attached to the template.
llvm-svn: 162371
|
| |
|
|
|
|
|
|
|
|
|
| |
to overwrite objects that might have been allocated into the type's
tail padding. This patch is missing some potential optimizations where
the destination is provably a complete object, but it's necessary for
correctness.
Patch by Jonathan Sauer.
llvm-svn: 162254
|
| |
|
|
|
|
|
|
| |
does not return true for all implicit decls currently.
This should fix PR13634 for now, but Decl::isImplicit() should be fixed, too.
llvm-svn: 162238
|
| |
|
|
|
|
| |
declaration it was attached to.
llvm-svn: 162033
|
| |
|
|
| |
llvm-svn: 162005
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reason for the recent fallout for "attaching comments to any redeclaration"
change are two false assumptions:
(1) a RawComment is attached to a single decl (not true for 'typedef struct X *Y'
where we want the comment to be attached to both X and Y);
(2) the whole redeclaration chain has only a single comment (obviously false, the
user can put a separate comment for each redeclaration).
To fix (1) I revert the part of the recent change where a 'Decl*' member was
introduced to RawComment. Now ASTContext has a separate DenseMap for mapping
'Decl*' to 'FullComment*'.
To fix (2) I just removed the test with this assumption. We might not parse
every comment in redecl chain if we already parsed at least one.
llvm-svn: 161878
|
| |
|
|
|
|
| |
evaluated into a CXXTypeid member function. No functionality change.
llvm-svn: 161779
|
| |
|
|
|
|
|
|
| |
'templated' declaration for a function or class template to refer to
the function or class template itself, to which the documentation will
be attached. Fixes PR13593.
llvm-svn: 161762
|
| |
|
|
|
|
|
|
| |
Not only look for the comment near the declaration itself, but also walk the
redeclaration chain: the previous declaration might have had a documentation
comment.
llvm-svn: 161722
|
| |
|
|
| |
llvm-svn: 161548
|
| |
|
|
| |
llvm-svn: 161211
|
| |
|
|
| |
llvm-svn: 161186
|
| |
|
|
|
|
|
|
|
|
| |
The only caveat is renumbering CXCommentKind enum for aesthetic reasons -- this
breaks libclang binary compatibility, but should not be a problem since API is
so new.
This also fixes PR13372 as a side-effect.
llvm-svn: 161087
|
| |
|
|
|
|
|
|
|
| |
hex: ) during comment parsing.
Now internal representation of plain text in comment AST does not contain
character references, but the characters themselves.
llvm-svn: 160891
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).
EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.
This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.
The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.
Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).
llvm-svn: 160847
|
| |
|
|
|
|
|
|
|
|
| |
given declaration.
It is based on the observation that during parsing the comment that should be
attached to the decl is usually among the last two documentation comments
parsed.
llvm-svn: 160400
|
| |
|
|
|
|
|
|
|
| |
being a property of a canonical type to being a property of the fully-sugared
type. This should only make a difference in the case where an alias template
ignores one of its parameters, and that parameter is an unexpanded parameter
pack.
llvm-svn: 160244
|
| |
|
|
|
|
|
|
|
|
| |
due to
AVX). Currently, if no aligned attribute is specified the alignment of a vector is
inferred from its size. Thus, very large vectors will be over-aligned with no
benefit. Target owners should set this target max.
llvm-svn: 160209
|
| |
|
|
|
|
| |
declarations.
llvm-svn: 160156
|
| |
|
|
|
|
| |
PR12785
llvm-svn: 160121
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
diagnostics implemented -- see testcases.
I created a new TableGen file for comment diagnostics,
DiagnosticCommentKinds.td, because comment diagnostics don't logically
fit into AST diagnostics file. But I don't feel strongly about it.
This also implements support for self-closing HTML tags in comment
lexer and parser (for example, <br />).
In order to issue precise diagnostics CommentSema needs to know the
declaration the comment is attached to. There is no easy way to find a decl by
comment, so we match comments and decls in lockstep: after parsing one
declgroup we check if we have any new, not yet attached comments. If we do --
then we do the usual comment-finding process.
It is interesting that this automatically handles trailing comments.
We pick up not only comments that precede the declaration, but also
comments that *follow* the declaration -- thanks to the lookahead in
the lexer: after parsing the declgroup we've consumed the semicolon
and looked ahead through comments.
Added -Wdocumentation-html flag for semantic HTML errors to allow the user to
disable only HTML warnings (but not HTML parse errors, which we emit as
warnings in -Wdocumentation).
llvm-svn: 160078
|
| |
|
|
| |
llvm-svn: 159878
|
| |
|
|
|
|
|
|
| |
currently we take address of std::vector's contents only after we finished
adding all comments (so no reallocation can happen), this will change in
future.
llvm-svn: 159845
|
| |
|
|
| |
llvm-svn: 159830
|
| |
|
|
|
|
| |
NULL as int.
llvm-svn: 159818
|