These functions don't accept local variable heap memory, although the names make it sound like they work on anything. When you try, they mistakenly identify such things as ObjC objects, call through to the equivalent objc_* function, and crash confusingly. This adds Object to the name of each one to make it more clear what they accept.
rdar://problem/37285743
* Unify the capitalization across all user-visible error messages (fatal errors, assertion failures, precondition failures) produced by the runtime, standard library and the compiler.
* Update some more tests to the new expectations.
It is safe to test pointer equality of an unowned variable, even if
the unowned variable refers to a dead object. Allowing this operation
without an unnecessary unowned abort enables some kinds of caching
schemes more cheaply than can be done with weak variables.
rdar://32142240
Use the generic type lowering algorithm described in
"docs/CallingConvention.rst#physical-lowering" to map from IRGen's explosion
type to the type expected by the ABI.
Change IRGen to use the swift calling convention (swiftcc) for native swift
functions.
Use the 'swiftself' attribute on self parameters and for closures contexts.
Use the 'swifterror' parameter for swift error parameters.
Change functions in the runtime that are called as native swift functions to use
the swift calling convention.
rdar://19978563
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
