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: 203966
Per more discussion, 'objc_protocol_requires_explicit_implementation' is
refinement that it mainly adds that requirement that a protocol must be
explicitly satisfied at the moment the first class in the class hierarchy
conforms to it. Any subclasses that also conform to that protocol,
either directly or via conforming to a protocol that inherits that protocol,
do not need to re-implement that protocol.
Doing this requires first doing a pass on the super class hierarchy,
gathering the set of protocols conformed to by the super classes,
and then culling those out when determining conformance. This
two-pass algorithm could be generalized for all protocol checking,
and could possibly be a performance win in some cases. For now
we restrict this change to protocols with this attribute to isolate
the change in logic (especially as the design continues to evolve).
This change needs to be adjusted for properties as well; this
only impacts methods right now.
llvm-svn: 202948
This test also illustrates that checking for properties is not working properly with
this attribute, as we are missing a diagnostic for a property not being implemented.
llvm-svn: 202335
In particular, if we see an @property within the @interface of a class
conforming to a protocol with this attribute, we treat that as
if the implementation were available, per the rules of default
property synthesis.
llvm-svn: 201911
Thanks to r199467, __attribute__((nonnull)) (without arguments) can apply
directly to parameters, instead of being applied to the whole function.
However, the old form of nonnull (with an argument index) could also apply
to the arguments of function and block pointers, and both of these can be
passed as parameters.
Now, if 'nonnull' with an argument is found on a parameter, /and/ the
parameter is a function or block pointer, it is handled the old way.
PR18795
llvm-svn: 201162
parimary class and in mrr mode, assume property's default
memory attribute (assign) and to prevent a bogus warning.
// rdar://15859862
llvm-svn: 200238
not using backing ivar warning, ignore when
property is not being synthesized (user declared its
implementation @dynamic). // rdar://1583425
llvm-svn: 199820
This involved making CheckReturnStackAddr into a static function, which
is now called by a top-level return value checking routine called
CheckReturnValExpr.
llvm-svn: 199790
This attribute is supported by GCC. More generally it should
probably be a type attribute, but this behavior matches 'nonnull'.
This patch does not include warning logic for checking if a null
value is returned from a function annotated with this attribute.
That will come in subsequent patches.
llvm-svn: 199626
This allows the following syntax:
void baz(__attribute__((nonnull)) const char *str);
instead of:
void baz(const char *str) __attribute__((nonnull(1)));
This also extends to Objective-C methods.
The checking logic in Sema is not as clean as I would like. Effectively
now we need to check both the FunctionDecl/ObjCMethodDecl and the parameters,
so the point of truth is spread in two places, but the logic isn't that
cumbersome.
Implements <rdar://problem/14691443>.
llvm-svn: 199467
which may belong to unrelated classes. It was
primarily intended for miuse of @selector expression.
But warning is too noisy and will be issued when
an actual @selector is used. // rdar://15740134
llvm-svn: 198952
property has the naming convention that implies 'ownership'.
2) improve on diagnostic and make it property specific.
3) fix the line number in the case of default property
synthesis. // rdar://15757510
llvm-svn: 198905
Fixes <rdar://problem/15596883>
In ARC, __attribute__((objc_precise_lifetime)) guarantees that the
object stored in it will survive to the end of the variable's formal
lifetime. It is therefore useful even if it completely unused.
llvm-svn: 198888
- Remove the additions to ObjCMethodDecl & ObjCIVarDecl that were getting de/serialized and consolidate
all functionality for the checking for this warning in Sema::DiagnoseUnusedBackingIvarInAccessor
- Don't check immediately after the method body is finished, check when the @implementation is finished.
This is so we can see if the ivar was referenced by any other method, even if the method was defined after the accessor.
- Don't silence the warning if any method is called from the accessor silence it if the accessor delegates to another method via self.
rdar://15727325
llvm-svn: 198432
Fixes <rdar://problem/15584219> and <rdar://problem/12241361>.
This change looks large, but all it does is reuse and consolidate
the delayed diagnostic logic for deprecation warnings with unavailability
warnings. By doing so, it showed various inconsistencies between the
diagnostics, which were close, but not consistent. It also revealed
some missing "note:"'s in the deprecated diagnostics that were showing
up in the unavailable diagnostics, etc.
This change also changes the wording of the core deprecation diagnostics.
Instead of saying "function has been explicitly marked deprecated"
we now saw "'X' has been been explicitly marked deprecated". It
turns out providing a bit more context is useful, and often we
got the actual term wrong or it was not very precise
(e.g., "function" instead of "destructor"). By just saying the name
of the thing that is deprecated/deleted/unavailable we define
this issue away. This diagnostic can likely be further wordsmithed
to be shorter.
llvm-svn: 197627
of objc_bridge_related attribute; eliminate
unnecessary diagnostics which is issued elsewhere,
fixit now produces a valid AST tree per convention.
This results in some simplification in handling of
this attribute as well. // rdar://15499111
llvm-svn: 197436
Ted Kremenek