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
Clang's -Wformat fix-its currently suggest using "%zu" for values of
type size_t (in C99 or C++11 mode). However, for a type such as
std::vector<T>::size_type, it does not notice that type is actually
typedeffed to size_t, and instead suggests a format for the underlying
type, such as "%lu" or "%u".
This commit makes the format string fix mechanism walk the typedef chain
so that it notices if the type is size_t, even if that isn't "at the
top".
llvm-svn: 160886
This tests for the ability to include a "message" field in availability
attributes, like so:
extern void ATSFontGetName(const char *oName)
__attribute__((availability(macosx,introduced=8.0,deprecated=9.0,
message="use CTFontCopyFullName")));
This was actually supported in Clang 3.1, but we got a request for a
__has_feature so that header files can use this more safely. It's
unfortunate that the 3.1 release doesn't include this, however.
<rdar://problem/11886458>
llvm-svn: 160699
short-circuiting when building the CFG. Also be sure to skip parens before
checking for the && / || special cases. Finally, fix some crashes in CFG
printing in the presence of calls to destructors for array of array of class
type.
llvm-svn: 160691
variables that have static storage duration, it removes debug info on the
emitted initializer function but not all debug info about this variable.
llvm-svn: 160659
The assertion was wrong in case we have a verbatim block without a closing
command.
Also add tests for closing command name in a verbatim block, since now it can
be empty in such cases.
llvm-svn: 160568
* Treat compound assignment as a use, at Jordy's request.
* Always add compound assignments into the CFG, so we can correctly diagnose the use in 'return x += 1;'
llvm-svn: 160334
use out of TransferFunctions, and compute it in advance rather than on-the-fly.
This allows us to handle compound assignments with DeclRefExprs on the RHS
correctly, and also makes it trivial to treat const& function parameters as not
initializing the argument. The patch also makes both of those changes.
llvm-svn: 160330
struct __attribute__((visibility("hidden"))) zed {
};
struct __attribute__((visibility("hidden"))) zed;
Which is a bit silly and got a lot noisier now that we correctly handle
visibility pragmas. This patch fixes that and also has some extra quality
improvements:
* We now produce an error instead of a warning for
struct __attribute__((visibility("hidden"))) zed {
};
struct __attribute__((visibility("default"))) zed;
* The "after definition" warning now points to the new attribute that is
ignored instead of pointing to the declaration.
llvm-svn: 160227
instead push the terminator for the branch down into the basic blocks of the subexpressions of '&&' and '||'
respectively. This eliminates some artifical control-flow from the CFG and results in a more
compact CFG.
Note that this patch only alters the branches 'while', 'if' and 'for'. This was complex enough for
one patch. The remaining branches (e.g., do...while) can be handled in a separate patch, but they
weren't immediately tackled because they were less important.
It is possible that this patch introduces some subtle bugs, particularly w.r.t. to destructor placement.
I've tried to audit these changes, but it is also known that the destructor logic needs some refinement
in the area of '||' and '&&' regardless (i.e., their are known bugs).
llvm-svn: 160218
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
This behaves like the existing GNU __alignof and C++11 alignof keywords;
most of the patch is simply adding the third token spelling to various places.
llvm-svn: 159494
This adds support for the tls_model attribute. This allows the user to
choose a TLS model that is better than what LLVM would select by
default. For example, a variable might be declared as:
__thread int x __attribute__((tls_model("initial-exec")));
if it will not be used in a shared library that is dlopen'ed.
This depends on LLVM r159077.
llvm-svn: 159078
Also, don't warn if the used function is __attribute__((const)), in which case
it's not supposed to use global variables anyway.
The inline-in-inline thing is a heuristic, and one that's possibly incorrect
fairly often because the function being inlined could definitely use global
variables. However, even some C standard library functions are written using
other (trivial) static-inline functions in the headers, and we definitely don't
want to be warning on that (or on anything that /uses/ these trivial inline
functions). So we're using "inlined" as a marker for "fairly trivial".
(Note that __attribute__((pure)) does /not/ guarantee safety like ((const),
because ((const)) does not guarantee that global variables are not being used,
and the warning is about globals not being shared across TUs.)
llvm-svn: 158898
Now that this is a C-only warning, we can use "static" instead of "internal
linkage", which is a term developers are probably more familiar with.
This makes for a better warning message. The warning name was changed to match,
since "internal linkage" is not mentioned in the warning text anymore.
llvm-svn: 158853
The original r158700 caused crashes in the gcc test suite,
g++.abi/vtable3a.C among others. It also caused failures in the libc++
test suite.
llvm-svn: 158749
Per post-commit review, it's not appropriate to use ExtWarn in C++, because
we can't prove that the inline function will actually be defined in more than
one place (and thus we can't prove that this violates the ODR).
This removes the warning entirely from uses in the main source file in C++.
llvm-svn: 158689
This includes treating anonymous namespaces like internal linkage, and allowing
const variables to be used even if internal. The whole thing's been broken out
into a separate function to avoid nested ifs.
llvm-svn: 158683
This handles the very common case of people writing inline functions in their
main source files and not tagging them as inline. These cases should still
behave as the user intended. (The diagnostic is still emitted as an extension.)
I'm reworking this code anyway to account for C++'s equivalent restriction in
[basic.def.odr]p6, but this should get some bots back to green.
llvm-svn: 158666
Hans Wennborg