temporaries with no-return destructors. The CFG now properly supports
temporaries and implicit destructors which both makes this kludge no
longer work, and conveniently removes the need for it.
Turn on CFG handling of implicit destructors and initializers. Several
ad-hoc benchmarks don't indicate any measurable performance impact from
growing the CFG, and it fixes real correctness problems with warnings.
As a result of turning on these CFG elements, we started to tickle an
inf-loop in the unreachable code logic used for warnings. The fix is
trivial.
llvm-svn: 123056
int x = 42;
x = x; // Warns here.
The warning avoids macro expansions, templates, user-defined assignment
operators, and volatile types, so false positives are expected to be low.
The common (mis-)use of this code pattern is to silence unused variable
warnings, but a more idiomatic way of doing that is '(void)x;'.
A follow-up to this will add a note and fix-it hint suggesting this
replacement in cases where the StmtExpr consists precisely of the self
assignment.
llvm-svn: 122804
declaration name of the array when present. This ensures that
a poor-man's C++03 static_assert will include the user error message
often embedded in the name.
Update all the tests to reflect the new wording, and add a test for the
name behavior.
llvm-svn: 122802
test due to recent changes to the CFG. The
diagnostic is somewhat in the wrong place, but
the -Wunreachable-code diagnostic needs to be
revamped anyway since most of the diagnostics
in this test case are redundant.
llvm-svn: 121961
would return true if the initializer pointer union had *any* non-null
pointer in it, even if the pointer wasn't one that would actually be
returned via getInit(). This makes it more accurately model the logic of
'getInit() != NULL'.
This still isn't completely satisfying. From a principled stance,
I suspect we should make hasInit() and getInit() *always* return false
and NULL (resp.) for ParmVarDecl. We shouldn't at the API level treat
initializers and default arguments as the same thing.
llvm-svn: 121692
not actually frequently used, because ImpCastExprToType only creates a node
if the types differ. So explicitly create an ICE in the lvalue-to-rvalue
conversion code in DefaultFunctionArrayLvalueConversion() as well as several
other new places, and consistently deal with the consequences throughout the
compiler.
In addition, introduce a new cast kind for loading an ObjCProperty l-value,
and make sure we emit those nodes whenever an ObjCProperty l-value appears
that's not on the LHS of an assignment operator.
This breaks a couple of rewriter tests, which I've x-failed until future
development occurs on the rewriter.
Ted Kremenek kindly contributed the analyzer workarounds in this patch.
llvm-svn: 120890
disambiguate between an expression (for a bit-field width) and a type
(for a fixed underlying type). Since the disambiguation can be
expensive (due to tentative parsing), we perform a simplistic
disambiguation based on one-token lookahead before going into the
full-blown tentative parsing. Based on a patch by Daniel Wallin.
llvm-svn: 120582
a useful template instantiation stack. Fixes PR8640.
This also causes a slight change to where the "instantianted from" note shows up
in truly esoteric cases (see the change to test/SemaCXX/destructor.cpp), but
that isn't directly the fault of this patch.
llvm-svn: 120135
producing warnings.
This feels really fragile, and I've not audited all other argument index-based
warnings. I suspect we'll grow this bug on another warning eventually. It might
be nice to adjust the argument indices when building up the attribute AST node,
as we already have to remember about the 'this' argument within that code to
produce correct errors.
llvm-svn: 119340
argument indexes. This handles the offsets in a consistent manner for all of
the attributes which I saw working with these concepts. I've also added tests
for the attribute that motivated this: nonnull.
I consolidated the tests for format attributes into one file, and fleshed them
out a bit to trigger more of the warning cases. Also improved the quality of
some of the diagnostics that occur with invalid argument indices.
The only really questionable change here is supporting the implicit this
argument for the ownership attribute. I'm not sure it's really a sensible
concept there, but implemented the logic for consistency.
llvm-svn: 119339
That bug concerned the well-formedness of code such as (&ovl)(a, b,
c). GCC rejects the code, while EDG accepts it. On further study of the
standard, I see no support for EDG's position: in particular, C++
[over.over] does not list this as a context where we can take the
address of an overloaded function, C++ [over.call.func] does not
reference the address-of operator at any point, and C++ [expr.call]
claims that the function argument in a call is either a function
lvalue or a pointer-to-function; (&ovl) is neither.
llvm-svn: 118620
Rafael Espindola