This is a bit of a hodge-podge of related changes that I decided
weren't quite worth teasing apart:
First, rename the weak{Retain,Release} entrypoints to
unowned{Retain,Release} to better reflect their actual use
from generated code.
Second, standardize the names of the rest of the entrypoints around
unowned{operation}.
Third, standardize IRGen's internal naming scheme and API for
reference-counting so that (1) there are generic functions for
emitting operations using a given reference-counting style and
(2) all operations explicitly call out the kind and style of
reference counting.
Finally, implement a number of new entrypoints for unknown unowned
reference-counting. These entrypoints use a completely different
and incompatible scheme for working with ObjC references. The
primary difference is that the new scheme abandons the flawed idea
(which I take responsibility for) that we can simulate an unowned
reference count for ObjC references, and instead moves towards an
address-only scheme when the reference might store an ObjC reference.
(The current implementation is still trivially takable, but that is
not something we should be relying on.) These will be tested in a
follow-up commit. For now, we still rely on the bad assumption of
reference-countability.
We can't do this because the object was deallocated. However, ASan should flag us if we regress on touching deallocated unowned-referenced objects though, so we don't need this. rdar://problem/19677703
Swift SVN r24894
ObjC unowned references are backed by an ObjC weak reference which will eagerly deallocate the object when it's strongly released, so in an unknown-refcount situation, we can't safely dereference the object pointer to determine its Swiftness. We can, however, look at the side table of weak references; if there's an entry for this object, then it's reliably an ObjC object (or it's some other object that got allocated in the reclaimed space for the dead object, but that's a race we fundamentally can't win with this broken design). Fixes rdar://problem/18091547 (modulo the aforementioned reallocation race).
Swift SVN r24825
Instead of directly referencing a long-dead constructor from the standard library, put a purpose-built function in StdlibUnittest to feed a Swift object reference to the test C code. rdar://problem/18498737
Swift SVN r24816
