This replaces the '[volatile]' flag. Now, class_method and
super_method are only used for vtable dispatch.
The witness_method instruction is still overloaded for use
with both ObjC protocol requirements and Swift protocol
requirements; the next step is to make it only mean the
latter, also using objc_method for ObjC protocol calls.
introduce a common superclass, SILNode.
This is in preparation for allowing instructions to have multiple
results. It is also a somewhat more elegant representation for
instructions that have zero results. Instructions that are known
to have exactly one result inherit from a class, SingleValueInstruction,
that subclasses both ValueBase and SILInstruction. Some care must be
taken when working with SILNode pointers and testing for equality;
please see the comment on SILNode for more information.
A number of SIL passes needed to be updated in order to handle this
new distinction between SIL values and SIL instructions.
Note that the SIL parser is now stricter about not trying to assign
a result value from an instruction (like 'return' or 'strong_retain')
that does not produce any.
The allocating thunk handles the `dynamic`-ness of the initializing entry point, which maps to an underlying `-initWith*:` ObjC method, and cannot itself be treated as `dynamic`. Fixes SR-5223 | rdar://problem/32778104.
All we need to store is whether the SILDeclRef directly
references the declaration, or if it references a curry
thunk, and we already have an isCurried bit for that.
While it is currently true that the first entry in a SubstitutionList
of a protocol requirement is the Self type, this was not always true
in the past, and it might change again in the future. Don't rely on
this behavior.
This fixes a crash when referencing partially-applied methods
from @_inlineable functions.
Also, curry thunks for private methods do not need shared
linkage; private is sufficient.
This generalizes a hack where re-abstraction thunks become fragile on contact
with fragile functions.
The old policy was:
- [fragile] functions always serialized
- [reabstraction_thunk] transitively referenced from fragile always serialized
The new policy is:
- [serialized] functions always serialized
- [serializable] functions transitively referenced from serialized functions
are always serialized
- Most kinds of thunks can now be [serializable], allowing them to be shared
between serialized and non-serialized code without any issues, as long as the
body of the thunk is sufficiently "simple" (doesn't reference private
symbols or performs direct access to resilient types)
Also, add a third [serializable] state for functions whose bodies we
*can* serialize, but only do so if they're referenced from another
serialized function.
This will be used for bodies synthesized for imported definitions,
such as init(rawValue:), etc, and various thunks, but for now this
change is NFC.
Now that methods are the only case where we have a function
with multiple parameter lists, we can remove the logic for
forwarding captures (methods cannot have captures), and
simplify what remains to only deal with the case of a single
'self' argument being curried.
