Adjust the IRGen for ObjC interop to ensure that the section that
metadata is emitted into the correct section for non-MachO targets.
This also adds a more comprehensive test for ensuring that the IRGen can
now be tested on all targets. Since the ObjC interop is now
controllable via the driver, this test does not require that the
objc_interop feature is present as it is a IRGen test.
This is the first step to remove the `REQUIRES: objc_interop` from the
IRGen tests.
Following up on the fixes for rdar://problem/35330067. If a class inherits a class from another module with missing fields, we need to treat its size and alignment as opaque, just like the base class itself. We also need to lay out such class at runtime, since we don't know the size, alignment, or field offsets at compile time; relying on the ObjC runtime alone will slide the ivar offsets, but not the Swift instance size and alignment. Fixes rdar://problem/35747485.
We would miscompile in mixed-language-version projects when a Swift class was compiled for one language version, while using Objective-C-imported types that are only available to that version, and then imported into a Swift module with a different language version that wasn't able to see all of the properties because of incompatible imported types. This manifested in a number of ways:
- We assumed we could re-derive the constant field offsets of the class's ivars from the layout, which is wrong if properties are missing, causing accesses to final properties or subclass properties to go to the wrong offsets.
- We assumed we could re-derive the instance size and alignment of a class instance in total, causing code to allocate the wrong amount of memory.
- We neglected to account for the space that stored properties take up in the field offset vector of the class object, causing us to load vtable entries for following subclass methods from the wrong offsets.
Eventually, resilience should reduce our exposure to these kinds of problems. As an incremental step in the right direction, when we look at a class from another module in IRGen, treat it as always variably-sized, so we don't try to hardcode offsets, size, or alignment of its instances. When we import a class, and we're unable to import a stored property, leave behind a new kind of MissingMemberDecl that records the number of field offset vector slots it will take up, so that we lay out subclass objects and compute vtable offsets correctly. Fixes rdar://problem/35330067.
A side effect of this is that the RemoteAST library is no longer able to provide fixed field offsets for class ivars. This doesn't appear to impact the lldb test suite, and they will ultimately need to use more abstract access patterns to get ivar offsets from resilient classes (if they aren't already), so I just removed the RemoteAST test cases that tested for class field offsets for now.
This commit is mostly refactoring.
*) Introduce a new OptimizationMode enum and use that in SILOptions and IRGenOptions
*) Allow the optimization mode also be specified for specific SILFunctions. This is not used in this commit yet and thus still a NFC.
Also, fixes a minor bug: we didn’t run mandatory IRGen passes for functions with @_semantics("optimize.sil.never")
Switch most general endpoint to be `flags, parameters, parameterFlags, result`,
instead of opaque `void **`, more specialized ones to use follow argument scheme:
`flags, param0, [flags0], ..., paramN, [flagsN], result` and store parameter/flags
information separately in `FunctionCacheEntry::{Key, Data}` as well.
Currently only single 'inout' flag has been encoded into function
metadata, these changes extend function metadata to support up to
32 flags per parameter.
Switch most general endpoint to be `flags, parameters, parameterFlags, result`,
instead of opaque `void **`, more specialized ones to use follow argument scheme:
`flags, param0, [flags0], ..., paramN, [flagsN], result` and store parameter/flags
information separately in `FunctionCacheEntry::{Key, Data}` as well.
Currently only single 'inout' flag has been encoded into function
metadata, these changes extend function metadata to support up to
32 flags per parameter.
This is a small code size win, and also gives us some abstraction so that future cooperative ObjC compilers/runtimes might be able to interoperate ObjC class objects with Swift type metadata efficiently than they currently are in the fragile Swift runtime.
While I'm here, I also noticed that swift_getObjCClassMetadata was unnecessarily getting exposed in non-ObjC-interop runtime builds, so I fixed that as well.
This changes layout of the parameter metadata from single tuple record
(in case of materializable type) to N records each corresponding to
invididual function parameter, where functions with no parameters
`() -> Void` get 0 records allocated.
Alter the value metadata layout to use an absolute pointer for the
nominal type descriptor rather than a relative offset relative to the
complete type metadata. Although this is slightly less efficient in
terms of load times, this is more portable across different
environments. For example, PE/COFF does not provide a cross-section
relative offset relocation. Other platform ports are unable to provide
a 64-bit relative offset encoding.
Given that the value witness table reference in the value metadata is
currently an absolute pointer, this page is most likely going to be
dirtied by the loader.
Finally, remove the parent type metadata argument from type
constructors.
Now that type constructors don't take a parent metadata pointer,
we can hit some asserts concerning type constructors that do not
have any parameters. This happens when you define a concrete type
in a fully-constrained extension of a generic type.
A more efficient ABI would use concrete type metadata for these
cases, but that would be a bigger change that we can do later, so
for now just relax these assertions.
This resolves a runtime crasher since a circular metadata case is
no longer circular. I renamed the crasher to reference the more
specific radar since the more general issue of circular metadata
is still unresolved.
We no longer need this for anything, so remove it from metadata
altogether. This simplifies logic for emitting type metadata and
makes type metadata smaller.
We still pass the parent metadata pointer to type constructors;
removing that is a separate change.
This change makes it so that type metadata stores arguments
from each nesting depth. This means that parent metadata is
no longer needed to fulfill generic arguments, but we still
store a parent pointer in metadata and pass it to type
constructor functions at this point.
Once generic type metadata includes arguments from all outer contexts,
we need to know how many arguments there are at each nesting depth in
order to properly reconstruct the type name from metadata.
We were inlining the size and alignment, which was not correct.
This was the cause of a long-standing ASAN failure in some
library evolution tests.
Fixes <rdar://problem/24540778>.
- Always include an array of requirement descriptors in the protocol
descriptor. For now, this doesn't contain anything except a general
requirement kind and an optional default implementation, but eventually
this can be augmented with type / name metadata. This array is always
emitted as constant.
- Guarantee the value of the extent fields in a protocol descriptor and
slightly tweak their meaning.
- Move the private-data field out of line in a generic witness table
descriptor so that the main descriptor can be emitted as constant.
- Rely on IRGen's notion of the witness-table layout instead of assuming
that SILWitnessTable and SILDefaultWitnessTable match the actual
physical layout.
This version of the patch uses a hack in which we assign internal rather
than private linkage to certain symbols in order to work around a Darwin
linker bug.
Previous patches changed the runtime to copy the vtable from the
superclass rather than IRGen emitting it statically for generic
and resilient classes.
However for generic classes we would still copy the vtable entries
for methods defined in the immediate class from the template.
Instead, store them in the nominal type descriptor, where they use
less space since we can use relative pointers, and copy them out of
there.
This will allow us to 'slim down' generic class templates eventually.
Instead of emitting the vtable statically, copy it from the
superclass, and fill in method overrides, if any.
For now this is only done for classes initialized by
swift_initClassMetadata_UniversalStrategy(); I need to
add a new entry point for classes with static field
layout but a dynamic vtable.
