We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy rather than make a sweeping change
across a project. However, Clang is in a somewhat special circumstance
currently: recently, I've had several new contributors run into rdar
links around test code which their patch was changing the behavior of.
This turns out to be a surprisingly bad experience, especially for
newer folks, for a handful of reasons: not understanding what the link
is and feeling intimidated by it, wondering whether their changes are
actually breaking something important to a downstream in some way,
having to hunt down strangers not involved with the patch to impose on
them for help, accidental pressure from asking for potentially private
IP to be made public, etc. Because folks run into these links entirely
by chance (through fixing bugs or working on new features), there's not
really a set of problematic links to focus on -- all of the links have
basically the same potential for causing these problems. As a result,
this is an omnibus patch to remove all such links.
This was not a mechanical change; it was done by manually searching for
rdar, radar, radr, and other variants to find all the various
problematic links. From there, I tried to retain or reword the
surrounding comments so that we would lose as little context as
possible. However, because most links were just a plain link with no
supporting context, the majority of the changes are simple removals.
Differential Review: https://reviews.llvm.org/D158071
An upcoming patch will be making all defining or undefining of
predefined macros to be warning (currently only some give a warning).
In preparation for this adjust some tests that would emit a warning:
* In thread-specifier.c the undefine is done to avoid a different
warning, but we get that warning just because __thread and
__private_extern__ are the wrong way around so we can just swap
them.
* There are a couple of objective-c tests that redefine IBAction to
what it's already defined as, so we can just remove the define.
method declaration into its implementation to
prevent a bogus warning about mismatched attributes.
then make sure the warning about missing call to super comes out
of the method implementation. // rdar://14251387
llvm-svn: 185974
Also, unify ObjCShouldCallSuperDealloc and ObjCShouldCallSuperFinalize.
The two have identical behavior and will never be active at the same time.
There's one last simplification now, which is that if we see a call to
[super foo] and we are currently in a method named 'foo', we will
/unconditionally/ clear the ObjCShouldCallSuper flag, rather than check
first to see if we're in a method where calling super is required. There's
no reason to pay the extra lookup price here.
llvm-svn: 166285
in classes. Use it to flag those method implementations which don't
contain call to 'super' if they have 'super' class and it has the method
with this attribute set. This is wip. // rdar://6386358
llvm-svn: 163434