If a thunk is referenced from two different functions, the thunk inherits
the fragile attribute from the first function that forced it to be emitted.
This is wrong, in case the first function might not be fragile, while
the second one is. Copying the fragile attribute to an existing thunk when
checking if it has already been emitted is also wrong, because the thunk
might reference another thunk, and so on.
The correct fix is to have SIL serialization serialize the transitive
closure of all fragile functions and thunks referenced from fragile
functions. Re-work SIL function serialization to use a worklist so that
we can do this.
Part of https://bugs.swift.org/browse/SR-267.
A transparent function might be deserialized and inlined into a function
in another module, which would cause problems if the function referenced
local functions.
Previously we would force local functions to have public linkage instead,
which worked, but was not resilient if the body of the transparent
function changed in the module that contained it.
Add a library evolution test ensuring that such a change is resilient
now.
Part of https://bugs.swift.org/browse/SR-267.
This test ensures that the runtime correctly instantiates resilient conformances,
and that IRGen emits the correct metadata, allowing a conformance that was
compiled before a new requirement was added to present a default implementation
of this requirement.
For now, this runs with --no-backward-deployment, so we only test before/before,
before/after and after/after cases.
Getting after/before working is also an expected capability here, but requires
IRGen witness table emission to know which requirements were satisfied by
defaults, so that they can be dropped if they appear at the end of a witness
table. In turn, this requires serializing SILDefaultWitnessTables. This will
be added in a subsequent patch.
In addition to fixing the above case, I need to write additional tests and
possibly fix bugs related to more elaborate cases involving generics, as well as
default witnesses for properties and subscripts.
Even dynamically casting a generic parameter to a protocol type is only
guaranteed to succeed for conformances available at build time.
Since we can't express conditional availability of conformances yet,
this part of the test is useless, so redo it.
I'm going to add some more tests related to @_transparent shortly,
and it is important to verify that bodies of @_transparent functions
are serialized (at least in single-frontend mode, for now).
I realize this test is probably too specific, since in the future
we may sometimes choose not to inline @_transparent functions into
their callers, even if a serialized body is available; but this
will suffice for now.
We now test four setups, with the four {before, after}^2 runs of each:
a) Client adds conformance -vs- library adds public conformance -- fixed-layout struct
b) Client adds conformance -vs- library removes internal conformance -- fixed-layout struct
c) Client adds conformance -vs- library adds public conformance -- resilient struct
d) Client adds conformance -vs- library removes internal conformance -- resilient struct
The first two pass, but a) requires a hack to ensure we don't
directly reference conformance table, otherwise the 'after_before'
version doesn't link. I think the right idea here is to weakly
reference conformance tables where the deployment target is
lower than the availability of the conformance.
The second two are XFAIL'd until protocol conformance tables can
reference resilient types from other modules. This requires emitting
indirect metadata symbols, since the client doesn't know if the
resilient type's metadata is direct or a template, and the
conformance table cannot use the metadata accessor either.
These tests will also become important if we decide to revisit
synthesized accessors, and make them lazy again for structs.
