From what I see the only fields are DATA_VALUE_WITNESS which
all have type size_t. I converted them to use the target-dependent
`StoredSize`. While I was around I fixed also isValueInline()
to do the right thing (it was using ValueBuffer instead of
TargetValueBuffer) and all the getters for the data value witnesses.
<rdar://problem/41546568>
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.
In a generic requirement, distinguish between Swift and
Objective-C protocols using a spare bit within the relative
(indirectable) reference to the protocol.
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.
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.
'const T *' isn't compatible with a function pointer, so upstream
Clang complained about the 'patch_t' convenience constructor we were
using. It's not like we need general functionality or convenience
here, so just pass the members of the patch_t type separately and
without any templating, and drop it entirely.
No functionality change.
Follow-up to 3ed3774e07. On Apple OSs that don't have the new
Objective-C runtime function 'objc_setHook_getImageName', override the
system definition of 'class_getImageName' by literally rewriting
symbol tables at run time.
Yes, you read that correctly.
The low-level part of this patch was written by Greg Parker, then
simplified and tweaked by me to fit the Swift coding style. Don't try
this at home; it comes with all sorts of caveats and won't actually
work on this year's iOS. (Fortunately we don't need it there, because
that will have the new ObjC entry point.)
The rest of the patch is pretty straightforward: the replacement
implementation calls the code that supports Swift objects (the same
code we use on newer OSs), which then chains back to the original
system implementation of class_getImageName. May we never have to
touch this again.
rdar://problem/41535552
This not only restores the correct behavior for classes with generic
ancestry, but also handles actual generic classes as well. (This is
the function that backs Foundation's Bundle.init(for: AnyClass)
initializer.)
https://bugs.swift.org/browse/SR-1917
rdar://problem/33450609&40367300
This code would previously read off the end of the allocated metadata to fetch these values. This was usually harmless, as the value was never used in that case. However, on rare occasions the metadata would be right before unmapped memory, and this read would crash trying to access that unmapped memory.
rdar://problem/39866044
Dynamic subclasses aren't /really/ valid Swift type metadata, but
they can still be used as values of type AnyClass. Make sure we
don't assert when that happens.
No intended functionality change.
If we only emit an opaque reflection record for a struct or class, then we can't reflect its fields. We failed both to clear the "is reflectable" bit in the context descriptor for non-reflectable structs, and to check for the bit before trying to present a struct's fields as children in the runtime. rdar://problem/41274260
Clang-importer-synthesized declarations get an extra tag character included in their mangling, which was not being preserved in type context descriptors. This caused runtime lookup for these synthesized types to fail. Fix this by adding the tag information to type context descriptors and teaching the runtime to match it up when fetching metadata by mangled name. Fixes rdar://problem/40878715.
This provides a slight amount of defense against attackers constructing mangled names with offsets crafted to JOP the runtime into attacker-controlled code. (Someone could still find some random code or constant data artifact in a binary that *looks* like a mangled string with symbolic references and theoretically attack that way, but they at least wouldn't be able to construct their own string entirely.)
Protocol name mangling didn’t always go through a path that allowed the use
of standard substitutions. Enable standard substitutions for protocol name
manglings where they make sense.
Removes ~277k from the standard library binary size.
Since the mangling scheme and set of standard library types is effectively
fixed now, introduce known mangling substitutions for a number of new
standard library types, filling out the S[A-Za-z] space.
Reduces standard library binary size by ~195k.
LLVM r334283 changed StringRef::split(char) to be implemented using
StringRef::split(StringRef), which is not defined inline. Because Swift
uses StringRef without linking LLVM's libSupport.a, we can only use
functions that are defined inline in the headers. Swift currently only
builds LLVM for the host, so we cannot link libSupport.a without building
it for every target, which would be a big change. Instead, this changes
a few places in Swift to avoid using those split and rsplit functions.
rdar://problem/41029268
