Two years ago I added a compile-time "optimization" to
ObjCMethodDecl::findPropertyDecl: exit early if the current method is part
of a special Objective-C method family (like 'new' or 'init'). However, if a
property (declared with @property) has a name that matches a method family,
the getter picks up that family despite being declared by the property. The
early exit then made ObjCMethodDecl::findPropertyDecl decide that there
was no associated property, despite the method itself being marked as an
accessor. This corrects that by removing the early exit.
This does /not/ change the fact that such a getter is considered to return a
value with a +1 retain count. The best way to eliminate this is by adding the
objc_method_family(none) attribute to the getter, but unlike the existing
ns_returns_not_retained that can't be applied directly to the property -- you
have to redeclare the getter instead.
(It'd be nice if @property just implied objc_method_family(none) for its
getter, but that would be a backwards-incompatible change.)
rdar://problem/19038838
llvm-svn: 226338
of new warning for deprecated method call for receiver
of type 'id'. This addresses rdar://18960378 where
unintended warnings being issued.
llvm-svn: 221933
"protected scope" is very unhelpful here and actively confuses users. Instead,
simply state the nature of the problem in the diagnostic: we cannot jump from
here to there. The notes explain nicely why not.
llvm-svn: 217293
The -no-ns-alloc-error migration option now causes the diagnostic to be ignored
completely. If this isn't desired, the error can be downgraded to a warning
using the usual -Wno-error=arcmt-ns-alloc.
Note that we can't use -verify right now on this test because
VerifyDiagnosticConsumer gets confused by multiple SourceManager instances,
which is presumably the reason it was XFAILed in the first place and why the
regression wasn't detected. We'll grep instead for now.
llvm-svn: 209172
rules: instead of requiring flexible array members to be POD, require them to
be trivially-destructible. This seems to be the only constraint that actually
matters here (and even then, it's questionable whether this matters).
llvm-svn: 198983
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
with the edit entries, instead of applying the changes"
(And also revert the follow-up r197086.)
This seems to have broken Linux builds, which were failing with the following:
/build/buildbot/osu8/clang-x86_64-linux-selfhost-rel/llvm.obj/Release+Asserts/lib/libclang.so:
error: undefined reference to
'clang::ento::objc_retain::CallEffects::getEffect(clang::ObjCMethodDecl const*)'
/build/buildbot/osu8/clang-x86_64-linux-selfhost-rel/llvm.obj/Release+Asserts/lib/libclang.so:
error: undefined reference to
'clang::ento::objc_retain::CallEffects::getEffect(clang::FunctionDecl const*)'
collect2: error: ld returned 1 exit status
llvm-svn: 197111
to a temp file directly.
This allows to combine the edits when they can be different based on whether you saw
the implementation or not, e.g. with the designated initializer migration.
llvm-svn: 197076
the ObjC implementation declarations, just don't change implementations for
classes that are not in the whitelisted headers.
For example, if we change a method to return 'instancetype' we should also
update the method definition in the implementation.
llvm-svn: 197075
This options accepts a path to a directory, collects the filenames of the files
it contains, and the migrator will only modify files with the same filename.
llvm-svn: 194710
NS_RETURNS_INNER_POINTER under -objcmt-returns-innerpointer-property
flag (off by default), as older compilers do not support such annotations.
// rdar://15396636
llvm-svn: 194100
do not remove the setter if its availability differs
from availability of the getter (which is now turned into
a property). Otherwise, synthesized setter will
inherit availability of the property (which is incorrect).
// rdar://15300059
llvm-svn: 193837
