006a0a494a
This change forces you to write ``@reparented` relationships
on an extension of a protocol, rather than on the protocol
itself.
The ProtocolConformance needs to be associated with some
GenericContext and IRGen expects it to be an ExtensionDecl.
That environment defines under what conditions the conformance
exists. We also need to define witnesses for the new parent's
requirements in an extension anyway, so it's a natural fit.
The previous workaround for this was kind of awful, as it'd
require searching all the protocol's extensions and "guess"
which extension they want to represent the conformance. While
we could try to synthesize an extension, there's two
challenges there:
1. Due to SuppressedAssociatedTypes, it's not so simple to
synthesize an unconstrained ExtensionDecl.
2. We currently rely on same-type requirements to pin the
associated types to particular witnesses of those requirements
in the extension. So it's not purely unconstrained! For example,
```
extension Seq: @reparented BorrowSeq where Iter == MyIter {}
```
The constraints that are disallowed (but not yet diagnosed)
are conditional conformance requirements, as the default
conformance for a reparenting cannot depend on those.
Thus, it's better that programmers to specify the extension.
Resilient Library Evolution Tests
This directory tests for the correctness of resilience, which is a
broad term for Swift maximizing binary compatibility of a dependency
while maintaining the freedom to do things that would normally break
clients in other languages, such as changing the layout of nominal
types. The detailed explanation of resilience is out of scope of this
little readme and can be found in docs/LibraryEvolution.rst.
Each main test file should compile against "before" and "after" versions of the corresponding library file. The old and new versions are selected via the BEFORE or AFTER preprocessor variables.
In the library, going from BEFORE to AFTER must be an ABI-compatible change, as documented in the library evolution specification.
In the main program, going from BEFORE to AFTER does not have to be backward compatible.
In the main file, use your test library's getVersion helper function
to know which version of the library to expect at runtime.
There are four valid combinations for each test:
- Main file compiled against old library, linked against old library a.k.a. "before before"
- Main file compiled against old library, linked against new library, a.k.a. "before after"
- Main file compiled against new library, linked against old library, a.k.a. "after before"
- Main file compiled against new library, linked against new library, a.k.a. "after after"
The version of the library available at compile time determines which serialized declarations and transparent function bodies are visible.
When adding a new test, see the boilerplate at the top of each file for
the general pattern for this kind of test. Use the StdlibUnittest
library for assertions.