Recent work on -Wunreachable-code has focused on suppressing uninteresting
unreachable code that center around "configuration values", but
there are still some set of cases that are sometimes interesting
or uninteresting depending on the codebase. For example, a dead
"break" statement may not be interesting for a particular codebase,
potentially because it is auto-generated or simply because code
is written defensively.
To address these workflow differences, -Wunreachable-code is now
broken into several diagnostic groups:
-Wunreachable-code: intended to be a reasonable "default" for
most users.
and then other groups that turn on more aggressive checking:
-Wunreachable-code-break: warn about dead break statements
-Wunreachable-code-trivial-return: warn about dead return statements
that return "trivial" values (e.g., return 0). Other return
statements that return non-trivial values are still reported
under -Wunreachable-code (this is an area subject to more refinement).
-Wunreachable-code-aggressive: supergroup that enables all these
groups.
The goal is to eventually make -Wunreachable-code good enough to
either be in -Wall or on-by-default, thus finessing these warnings
into different groups helps achieve maximum signal for more users.
TODO: the tests need to be updated to reflect this extra control
via diagnostic flags.
llvm-svn: 203994
'init' methods which are unavailable. Subclasses of NSObject
have to implement such methods as a common pattern to prevent
user's own implementation. // rdar://16305460
llvm-svn: 203984
complete. We hook into this check from a couple of other places (modules,
debug info) so it's not OK to elide the check if the type was already
complete.
llvm-svn: 203978
(for an integer too large for any signed type) from Warning to ExtWarn -- it's
ill-formed in C++11 and C99 onwards, and UB during translation in C89 and
C++98. Add diagnostic groups for two relevant diagnostics.
llvm-svn: 203974
'init' methods which are unavailable. Subclasses of NSObject
have to implement such methods as a common pattern to prevent
user's own implementation. // rdar://16305460
llvm-svn: 203966
This patch factors the bodies of 9 constructors out into a single initialization
method.
Reviewed By: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D3059
llvm-svn: 203846
Apparently the FIXME was overlooked when the source location information was
made available to the function.
Reviewed By: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D3058
llvm-svn: 203845
Drive-by fixing some incorrect types where a for loop would be improperly using ObjCInterfaceDecl::protocol_iterator. No functional changes in these cases.
llvm-svn: 203842
const-qualified parameter type and the defined with a non-const-qualified
parameter type, the parameter is not const inside its body. Ensure that
the type we use when instantiating the body is the right one. Patch by
suyog sarda!
This is still rather unsatisfactory; it seems like it might be better to
instantiate at least the function parameters, and maybe the complete function
declaration, when we instantiate the definition for such a member function
(instead of reusing the declaration from inside the instantiated class
definition).
llvm-svn: 203741
that implicitly converts to 'bool' (such as pointers, and the first operand of
?:). Clean up issues found by this. Patch by Stephan Tolksdorf!
llvm-svn: 203735
Someone could write:
if (0) {
__c11_atomic_load(ptr, memory_order_release);
}
or the equivalent, which is perfectly valid, so we shouldn't outright reject
invalid orderings on purely static grounds.
rdar://problem/16242991
llvm-svn: 203564
This is a conservative check, because it's valid for the expression to be
non-constant, and in cases like that we just don't know whether it's valid.
rdar://problem/16242991
llvm-svn: 203561
Ted Kremenek