Protocols are never generic, so don't inherit from
TrailingGenericContextObjects. Instead, directly use
swift::ABI::TrailingObjects. Since protocols are never generic, this
doesn't actually affect layout at all; it's cleanup.
These were used to encode the “inherited protocols” for Objective-C
Protocol structures. These are no longer a part of either Swift protocol
descriptors or the part of Objective-C Protocol structures that the
Swift runtime inspects.
Rather than storing a mangled name in a Swift protocol descriptor,
which encodes information that is redundant with the context of the
protocol, store an unmangled name as in nominal type descriptors. Update
the various places where this name is used to extract the demangle
tree from the context descriptors.
Reimplement protocol descriptors for Swift protocols as a kind of
context descriptor, dropping the Objective-C protocol compatibility
layout. The new protocol descriptors have several advantages over the
current implementation:
* They drop all of the unused fields required for layout-compatibility
with Objective-C protocols.
* They encode the full requirement signature of the protocol. This
maintains more information about the protocol itself, including
(e.g.) correctly encoding superclass requirements.
* They fit within the general scheme of context descriptors, rather than
being their own thing, which allows us to share more code with
nominal type descriptors.
* They only use relative pointers, so they’re smaller and can be placed
in read-only memory
Implements rdar://problem/38815359.
When reading the protocol metadata from existential type metadata,
check the “isObjC” bit and handle the reading of the Objective-C
protocol name (using TargetObjCProtocolPrefix) separately from the reading the name of a Swift protocol (using TargetProtocolDescriptor).
More preparation for separating the layout of these two entities.
Introduce TargetObjCProtocolPrefix, which describes just enough of the
Objective-C runtime’s Protocol structure to extract the name without
having to call Objective-C’s protocol_getName().
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
Remote mirrors was hitting an assertion failure due to a generic parameter not being concrete. This check catches that case early and returns a clean failure from getSubstMap, which callers can then handle appropriately.
It also hit a casting failure in visitDependentMemberTypeRef, which assumed that SubstBase was either a NominalTypeRef or a BoundGenericTypeRef. This does a dynamic cast with a graceful failure.
In general there is a tension in this code between its use in the runtime, where we usually want to treat bad data as a horrible bug and fail loudly, and its use in remote mirrors, where we need to assume that the data we're examining might be horribly broken and we just want to do the best we can. Longer term we might want to make this code configurable so that we can have an "assert and die" mode for the runtime, and a "fail gracefully" mode for remote mirrors.
rdar://problem/40136609
In a generic requirement, distinguish between Swift and
Objective-C protocols using a spare bit within the relative
(indirectable) reference to the protocol.
Now, an AbstractFunctionDecl always stores a single parameter list.
Furthermore, ConstructorDecl and DestructorDecl always store a
ParamDecl for 'self'.
FuncDecl only has a 'self' if it is a member of a nominal type or
extension, so we tail-allocate the storage for it.
Most ApplyExpr subclasses will now require a ParenExpr, TupleExpr, or TupleShuffleExpr around their argument lists. The exceptions are BinaryExpr, which requires a TupleExpr, and SelfApplyExpr and its subclasses, which allow anything (and only ever have one argument).
This change doesn’t fix any of the places where we actually generate these.
Switch one entry point in the runtime (swift_getExistentialTypeMetadata)
to use ProtocolDescriptorRef rather than a protocol descriptor. Update
IRGen to produce ProtocolDescriptorRef instances for its calls, setting
the discriminator bit appropriately.
Within the runtime, verify that all instances of ProtocolDescriptorRef have
the right layout, i.e., the discriminator bit is set for @objc protocols
but not Swift protocols.
There are two general constructor forms here:
- One took the number of parameter lists, to be filled in later.
Now, this takes a boolean indicating if there is an implicit
'self'.
- The other one took the actual parameter lists and filled them
in right away. This now takes a separate 'self' ParamDecl and
ParameterList.
Instead of storing the number of parameter lists, an
AbstractFunctionDecl now only needs to store if there is a 'self'
or not.
I've updated most places that construct AbstractFunctionDecls to
properly use these new forms. In the ClangImporter, there is
more code that remains to be untangled, so we continue to build
multiple ParameterLists and unpack them into a ParamDecl and
ParameterList at the last minute.
Use ProtocolDescriptorRefs within the runtime representation of
existential type metadata (TargetExistentialTypeMetadata) instead of
bare protocol descriptor pointers. Start rolling out the use of
ProtocolDescriptorRef in a few places in the runtime that touch this
code. Note that we’re not yet establishing any strong invariants on
the TargetProtocolDescriptorRef instances.
While here, replace TargetExistentialTypeMetadata’s hand-rolled pointer
arithmetic with swift::ABI::TrailingObjects and centralize knowledge of
its layout better.
In our ABI, we’re using some C++ ABI tricks to simplify the
implementation of the runtime. One of them, in FullMetadata, requires
that we inherit from classes that we would also like to make use
TrailingObjects. Remove the “final” assertion from TrailingObjects
so we can do so.
We promise to be careful.
TargetProtocolDescriptorRef provides a reference to either a Swift or
an Objective-C protocol, using a spare bit to indicate which kind of
protocol it is. At present, the protocol descriptor also has this
information (so this is redundant), but that will change shortly.
There are no clients of TargetProtocolDescriptorRef yet.
...but don't hook it up to anything yet.
This is the very very start of the module stability / textual
interfaces feature described at
https://forums.swift.org/t/plan-for-module-stability/14551/
For now I've just made it a frontend option (not a driver option),
which is good enough for testing.
As part of this, lift the now-unnecessary restriction against
combining a non-mutable addressor with a setter. I've also
tweaked some of the diagnostics.
This is in preparation for generalized accessors.
