Suppress the warning by just not emitting the report. The sink node
would get generated, which is fine since we did reach a bad state.
Motivation
Due to the way code is structured in some of these macros, we do not
reason correctly about it and report false positives. Specifically, the
following loop reports a use-after-free. Because of the way the code is
structured inside of the macro, the analyzer assumes that the list can
have cycles, so you end up with use-after-free in the loop, that is
safely deleting elements of the list. (The user does not have a way to
teach the analyzer about shape of data structures.)
SLIST_FOREACH_SAFE(item, &ctx->example_list, example_le, tmpitem) {
if (item->index == 3) { // if you remove each time, no complaints
assert((&ctx->example_list)->slh_first == item);
SLIST_REMOVE(&ctx->example_list, item, example_s, example_le);
free(item);
}
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172883 91177308-0d34-0410-b5e6-96231b3b80d8
The warning is still under -Wuninitialized (although technically this
is defined behavior), but under a subgroup -Wstatic-self-init.
This addresses PR 10265.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172878 91177308-0d34-0410-b5e6-96231b3b80d8
partially-substituted parameter pack in a template, forget about the
partially-substituted parameter pack: it is now completed. Fixes
<rdar://problem/12176336>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172859 91177308-0d34-0410-b5e6-96231b3b80d8
Makes sure that a deserialized macro is only added to the preprocessor macro definitions only once.
Unfortunately I couldn't get a reduced test case.
rdar://13016031
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172843 91177308-0d34-0410-b5e6-96231b3b80d8
r159549 / r159164 regressed clang to reject
struct s {};
struct s
operator++(struct s a)
{ return a; }
This fixes the regression. Richard, pleas check if this looks right.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172834 91177308-0d34-0410-b5e6-96231b3b80d8
This patch prepares being able to test for and fix more problems (see
FIXME in the test for example).
Previously we would output unwrapped lines for preprocessor directives
at the point where we also parsed the hash token. Since often
projections only terminate (and thus output their own unwrapped line)
after peeking at the next token, this would lead to the formatter seeing
the preprocessor directives out-of-order (slightly earlier). To be able
to correctly identify lines to merge, the formatter needs a well-defined
order of unwrapped lines, which this patch introduces.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172819 91177308-0d34-0410-b5e6-96231b3b80d8
').' is likely part of a builder pattern statement.
This is based upon a patch developed by Nico Weber. Thank you!
Before:
int foo() {
return llvm::StringSwitch<Reference::Kind>(name).StartsWith(
".eh_frame_hdr", ORDER_EH_FRAMEHDR).StartsWith(
".eh_frame", ORDER_EH_FRAME).StartsWith(".init", ORDER_INIT).StartsWith(
".fini", ORDER_FINI).StartsWith(".hash", ORDER_HASH).Default(ORDER_TEXT);
}
After:
int foo() {
return llvm::StringSwitch<Reference::Kind>(name)
.StartsWith(".eh_frame_hdr", ORDER_EH_FRAMEHDR)
.StartsWith(".eh_frame", ORDER_EH_FRAME)
.StartsWith(".init", ORDER_INIT).StartsWith(".fini", ORDER_FINI)
.StartsWith(".hash", ORDER_HASH).Default(ORDER_TEXT);
}
Probably not ideal, but makes many cases much more readable.
The changes to overriding-ftemplate-comments.cpp don't seem better or
worse. We should address those soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172804 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
#include <a> // for x
#include <a/b/c> // for yz
After:
#include <a> // for x
#include <a/b/c> // for yz
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172799 91177308-0d34-0410-b5e6-96231b3b80d8
decay the parameter type immediately; let CheckParameter() do its
job. Fixes <rdar://problem/12071218>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172780 91177308-0d34-0410-b5e6-96231b3b80d8
a template parameter; make that also include one that came from
'auto'. Fixes <rdar://problem/12078752>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172770 91177308-0d34-0410-b5e6-96231b3b80d8
return type of a function by canonicalizing them away. They are
useless anyway, and conflict with our rules for template argument
deduction and __strong. Fixes <rdar://problem/12367446>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172768 91177308-0d34-0410-b5e6-96231b3b80d8
Presumably, if the printf format has the sign explicitly requested, the user
wants to treat the data as signed.
This is a fix-up for r172739, and also includes several test changes that
didn't make it into that commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172762 91177308-0d34-0410-b5e6-96231b3b80d8
unsequenced operations in the RHS. We don't compare the RHS with the rest of
the expression yet; such checks will need care to avoid diagnosing unsequenced
operations which are both in conditionally-evaluated subexpressions which
actually can't occur together, such as in '(b && ++x) + (!b && ++x)'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172760 91177308-0d34-0410-b5e6-96231b3b80d8
AT_producer. Which includes clang's version information so we can tell
which version of the compiler was used.
This is second of the two steps to allow us to do this. The first was a
change to llvm-mc with revision 172630 to provide a method to set the
AT_producer string. This second step has the clang driver passing the value
of getClangFullVersion() via the new flag -dwarf-debug-producer when invoking
the integrated assembler on assembly source files. Then using the new
setDwarfDebugProducer() method to set the AT_producer string.
rdar://12888242
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172758 91177308-0d34-0410-b5e6-96231b3b80d8
the gcc driver and makes it possible to add -pie to $CC or similar and
have it apply in the right places.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172753 91177308-0d34-0410-b5e6-96231b3b80d8
It is valid to do this:
printf("%u", (int)x);
But if we see this:
printf("%lu", (int)x);
...our fixit should suggest %d, not %u.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172739 91177308-0d34-0410-b5e6-96231b3b80d8
Chandler Carruth
Ted Kremenek
Richard Smith
Argyrios Kyrtzidis
Anna Zaks
NAKAMURA Takumi
David Blaikie
Matt Beaumont-Gay
Jordan Rose
Douglas Gregor
DeLesley Hutchins
Akira Hatanaka
Bill Wendling
Nico Weber
Manuel Klimek
Will Dietz
Daniel Jasper
Chad Rosier
Kevin Enderby
Peter Collingbourne