Fix some review comments.
Add a test for deduction when std::initializer_list isn't available yet.
Fix redundant error messages. This fixes and outstanding FIXME too.
llvm-svn: 148735
Clang previously implemented -Wswitch-enum the same as -Wswitch. This patch
corrects the behavior to match GCC's. The critical/only difference being that
-Wswitch-enum is not silenced by the presence of a default case in the switch.
llvm-svn: 148679
For consistency with GCC & reasonable sanity. The FIXME suggests that the
original author was perhaps using the default check for some other purpose,
not realizing the more obvious limitation/false-negatives it creates, but this
doesn't seem to produce any regressions & fixes the included test.
llvm-svn: 148649
This warning acts as the complement to the main -Wswitch-enum warning (which
warns whenever a switch over enum without a default doesn't cover all values of
the enum) & has been an an-doc coding convention in LLVM and Clang in my
experience. The purpose is to ensure there's never a "dead" default in a
switch-over-enum because this would hide future -Wswitch-enum errors.
The name warning has a separate flag name so it can be disabled but it's grouped
under -Wswitch-enum & is on-by-default because of this.
The existing violations of this rule in test cases have had the warning disabled
& I've added a specific test for the new behavior (many negative cases already
exist in the same test file - and none regressed - so I didn't add more).
Reviewed by Ted Kremenek ( http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120116/051690.html )
llvm-svn: 148640
values and non-type template arguments of integral and enumeration types.
This change causes some legal C++98 code to no longer compile in C++11 mode, by
enforcing the C++11 rule that narrowing integral conversions are not permitted
in the final implicit conversion sequence for the above cases.
llvm-svn: 148439
Objective-C classes. This has two purposes: to consistently provide
"forward declaration here" notes when we hit an incomplete type, and
to give LLDB a chance to complete the type.
RequireCompleteType bits from Sean Callanan!
llvm-svn: 144573
property references to use a new PseudoObjectExpr
expression which pairs a syntactic form of the expression
with a set of semantic expressions implementing it.
This should significantly reduce the complexity required
elsewhere in the compiler to deal with these kinds of
expressions (e.g. IR generation's special l-value kind,
the static analyzer's Message abstraction), at the lower
cost of specifically dealing with the odd AST structure
of these expressions. It should also greatly simplify
efforts to implement similar language features in the
future, most notably Managed C++'s properties and indexed
properties.
Most of the effort here is in dealing with the various
clients of the AST. I've gone ahead and simplified the
ObjC rewriter's use of properties; other clients, like
IR-gen and the static analyzer, have all the old
complexity *and* all the new complexity, at least
temporarily. Many thanks to Ted for writing and advising
on the necessary changes to the static analyzer.
I've xfailed a small diagnostics regression in the static
analyzer at Ted's request.
llvm-svn: 143867
implicitly perform an lvalue-to-rvalue conversion if used on an lvalue
expression. Also improve the documentation of Expr::Evaluate* to indicate which
of them will accept expressions with side-effects.
llvm-svn: 143263
rvalue. An assertion to catch this is in ImpCastExprToType will follow, but
vector operations currently trip over this (due to omitting the usual arithmetic
conversions). Also add an assert to catch missing lvalue-to-rvalue conversions
on the LHS of ->.
llvm-svn: 143155
expressions: expressions which refer to a logical rather
than a physical l-value, where the logical object is
actually accessed via custom getter/setter code.
A subsequent patch will generalize the AST for these
so that arbitrary "implementing" sub-expressions can
be provided.
Right now the only client is ObjC properties, but
this should be generalizable to similar language
features, e.g. Managed C++'s __property methods.
llvm-svn: 142914
statements. As noted in the documentation for the AST node, the
semantics of __if_exists/__if_not_exists are somewhat different from
the way Visual C++ implements them, because our parsed-template
representation can't accommodate VC++ semantics without serious
contortions. Hopefully this implementation is "good enough".
llvm-svn: 142901
- Remodel Expr::EvaluateAsInt to behave like the other EvaluateAs* functions,
and add Expr::EvaluateKnownConstInt to capture the current fold-or-assert
behaviour.
- Factor out evaluation of bitfield bit widths.
- Fix a few places which would evaluate an expression twice: once to determine
whether it is a constant expression, then again to get the value.
llvm-svn: 141561
builtin types (When requested). This is another step toward making
ASTUnit build the ASTContext as needed when loading an AST file,
rather than doing so after the fact. No actual functionality change (yet).
llvm-svn: 138985
-Wunused was a mistake. It resulted in duplicate warnings and lots of
other hacks. Instead, this should be a special sub-category to
-Wunused-value, much like -Wunused-result is.
Moved to -Wunused-comparison, moved the implementation to piggy back on
the -Wunused-value implementation instead of rolling its own, different
mechanism for catching all of the "interesting" statements.
I like the unused-value mechanism for this better, but its currently
missing several top-level statements. For now, I've FIXME-ed out those
test cases. I'll enhance the generic infrastructure to catch these
statements in a subsequent patch.
This patch also removes the cast-to-void fixit hint. This hint isn't
available on any of the other -Wunused-value diagnostics, and if we want
it to be, we should add it generically rather than in one specific case.
llvm-svn: 137822
code is very likely to be buggy, but its going to require more
significant changes on the part of the user to correct it in this case.
llvm-svn: 137820
a complement to the warnings we provide in condition expressions. Much
like we warn on conditions such as:
int x, y;
...
if (x = y) ... // Almost always a typo of '=='
This warning applies the complementary logic to "top-level" statements,
or statements whose value is not consumed or used in some way:
int x, y;
...
x == y; // Almost always a type for '='
We also mirror the '!=' vs. '|=' logic.
The warning is designed to fire even for overloaded operators for two reasons:
1) Especially in the presence of widespread templates that assume
operator== and operator!= perform the expected comparison operations,
it seems unreasonable to suppress warnings on the offchance that
a user has written a class that abuses these operators, embedding
side-effects or other magic within them.
2) There is a trivial source modification to silence the warning for
truly exceptional cases:
(void)(x == y); // No warning
A (greatly reduced) form of this warning has already caught a number of
bugs in our codebase, so there is precedent for it actually firing. That
said, its currently off by default, but enabled under -Wall.
There are several fixmes left here that I'm working on in follow-up
patches, including de-duplicating warnings from -Wunused, sharing code
with -Wunused's implementation (and creating a nice place to hook
diagnostics on "top-level" statements), and handling cases where a proxy
object with a bool conversion is returned, hiding the operation in the
cleanup AST nodes.
Suggestions for any of this code more than welcome. Also, I'd really
love suggestions for better naming than "top-level".
llvm-svn: 137819
ActOnStartOfSwitchStmt (i.e. before binding up a full-expression)
instead of ActOnFinishSwitchStmt.
Among other things, this means that property l-values are properly
converted inside the full-expression.
llvm-svn: 137014
for-in statements; specifically, make sure to close over any
temporaries or cleanups it might require. In ARC, this has
implications for the lifetime of the collection, so emit it
with a retain and release it upon exit from the loop.
rdar://problem/9817306
llvm-svn: 136204
throw-expressions, such that we don't consider the NRVO when the
non-volatile automatic object comes from outside the innermost try
scope (C++0x [class.copymove]p13). In C++98/03, our ASTs were
incorrect but it didn't matter because IR generation doesn't actually
apply the NRVO here. In C++0x, however, we were moving from an object
when in fact we should have copied from it. Fixes PR10142 /
<rdar://problem/9714312>.
llvm-svn: 134548
