- Narrow the fix to classes with @objc ancestry only
- Pass -enable-class-resilience in class resilience executable test so that
we exercise resilience there
- Only enable fragile layout if the class has @objc ancestry
- Add an IRGen test
A lazy property setter stores a value to the underlying storage
of the lazy property. The underlying storage is private, and it
is not proper for a public transparent function body to reference
a private member.
In practice, this only failed if the private member had a
non-constant offset, which only occurs with subclasses of @objc
classes, and resilient classes.
For @objc classes we already had a workaround where no accessors
for stored properties are ever transparent. I put this in to fix
this very issue with lazy properties, but now I realize it was
the wrong workaround, because we still had this problem with
resilient classes.
Note that I'm keeping the logic which made @objc accessors
non-transparent in place, because there's a good chance we will
decide that field offset globals should always be private.
Also, to make this issue reproducible in the test, I changed the
resilience execution tests to build the resilient library as a
dylib and link against that instead of just linking .o files
together. This is because .o files can see each other's internal
symbols, so I was not able to reproduce the original failure
this way. I went ahead and updated the other resilient tests to
do this as well. Also, each test now builds in WMO and non-WMO
mode, to exercise different SIL linking behavior. Again, the
WMO variant was needed to reproduce the issue fixed by this
commit, because without WMO we currently discard serialized SIL,
so no cross-module inlining of the lazy property setter was
taking place.
This is needed if we compile StdlibUnittest with -sil-serialize-all
So far I added the imports only in files which needed them. But this may change, depending on the optimizer (inlining).
Adding them in all files doesn't harm and avoids confusion if someone makes an unrelated change which would result in such a linker error.
This was fixed by Luke Howard as part of some other changes in the
following patch:
<b5880f386b>
After rebasing my fix, I noticed most of it disappeared.
However, it's still worth checking in the tests.
Fixes <rdar://problem/24183374>.
Looks like subclassing classes with resiliently-sized properties works,
as long as the subclass is @_fixed_layout, so let's ensure that's tested.
We don't want @_fixed_layout classes to be a thing though, and we still
can't handle changes to the number of stored properties in a base class,
so a couple of tests are disabled until I land some more patches.
Now that all the machinery is in place, the ClassMetadataBuilder
can (more accurately) query the ClassLayout instead of trying to
re-derive whether the field offset vector is dependent, etc.
Apart from performing dynamic layout for resiliently-sized fields
in concrete classes, this also lets us *skip* dynamic layout
if we have a generic class without any dependent fields.
I haven't tested subclassing with resilient field layout yet, but
getting that working is the next step and should not be too much
work.
Also, swift_initClassMetadata_UniversalStrategy() only stores
the computed field offsets in the field offset globals when the
Objective-C runtime is available, because it gets the offset
pointers from the Objective-C class rodata. On Linux, we will
need to emit code to copy from the field offset vector into
field offset globals in IRGen. This is pretty easy, but I'll do
it in a follow-up patch so for now the new execution test is
XFAIL'd on Linux.
