- format specifies type 'wchar_t **' (aka 'int **') but the argument has type 'float *'
- format specifies type 'wchar_t **' (aka 'unsigned short **') but the argument has type 'float *'
llvm-svn: 163468
of a c-function for what it is. Otherwise, this func
is treated as an overloadable c-function resulting in
a crash much later. // rdar://11743706
llvm-svn: 163224
initiated enum constant has the same value as another enum constant.
For instance:
enum test { A, B, C = -1, D, E = 1 };
Clang will warn that:
A and D both have value 0
B and E both have value 1
A few exceptions are made to keep the noise down. Enum constants which are
initialized to another enum constant, or an enum constant plus or minus 1 will
not trigger this warning. Also, anonymous enums are not checked.
llvm-svn: 162938
This makes Clang produce an error for code such as:
__thread int x;
int *p = &x;
The lvalue of a thread-local variable cannot be evaluated at compile
time.
llvm-svn: 162835
name. This should reduce the amount of warning false positives about bad HTML
in comments when the comment author intended to put a reference to a template.
This change will also enable us parse the comment as intended in these cases.
Fixes part 1 of PR13374.
llvm-svn: 162407
specifier is unsed in a declaration; as it may not make the symbol
local to linkage unit as intended. Suggest using "hidden" visibility
attribute instead. // rdar://7703982
llvm-svn: 162138
function arguments and arguments for variadic functions are of a particular
type which is determined by some other argument to the same function call.
Usecases include:
* MPI library implementations, where these attributes enable checking that
buffer type matches the passed MPI_Datatype;
* for HDF5 library there is a similar usecase as MPI;
* checking types of variadic functions' arguments for functions like
fcntl() and ioctl().
llvm-svn: 162067
as it does something unexpected (but gcc compatible).
Suggest use of __attribute__((visibility("hidden")))
on declaration instead. // rdar://7703982
llvm-svn: 161972
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
'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
are not definitions. This follows the behavior of both gcc and earlier
versions of clang. Regression from r156531. <rdar://problem/12048621>.
llvm-svn: 161523
The implementation also includes a Relax NG schema and tests for the schema
itself. The schema is used in c-index-test to verify that XML documents we
produce are valid. In order to do the validation, we add an optional libxml2
dependency for c-index-test.
Credits for CMake part go to Doug Gregor. Credits for Autoconf part go to Eric
Christopher. Thanks!
llvm-svn: 161431
This is useful for example for %n in printf, which expects
a pointer to int with the same logic for checking as %d
would have in scanf.
llvm-svn: 161407
Doxygen manual claims that multiple \brief or \returns commands will be merged
together, but actual behavior is different (second \brief command becomes a
part of a discussion, second \returns becomes a "Returns: blah" paragraph on
its own). Anyway, it seems to be a bad idea to use multiple \brief or \returns
commands in a single command.
llvm-svn: 161325
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
While '%n' can be used for evil in an attacker-controlled format string, there
isn't any acute danger in using it in a literal format string with an argument
of the appropriate type.
llvm-svn: 160984
NAKAMURA Takumi