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.
