When mangling a dependent protocol conformance ref, the mangler currently uses `0_` to mean an unknown index and `N_` to mean the index `N - 1`. Unfortunately, this is somewhat confused: `0_` is actually the mangling for index 1, and index 0 is supposed to be mangled as just `_`, so true indexes are actually offset by 2. So the first thing to do here is to clarify what's going on throughout the mangler, demangler, and ABI documentation.
Also, the demangler attempts to produce a `DependentProtocolConformance*` node with the appropriate child nodes and an optional index payload. Unfortunately, demangle nodes cannot have both children and a value payload, so whenever it creates a node with an index payload, the demangler will assert. It does this whenever the mangled index is not 0; since (per above) the mangler always produces a non-zero mangled index in this production, the demangler will always assert when processing these. So clearly this is well-tested code, since +asserts builds will always trigger the demangler when mangling a name in the first place. To fix this, we need to make the index a child of the mangling node instead of its payload; at the same time, we can make it store the semantically correct index value and just introduce a new `UnknownIndex` node to handle the `0_` case. This is easy because all current clients ignore this information.
Finally, due to an apparent copy-and-paste error, the demangler attempts to produce a `DependentProtocolConformanceRoot` node for associated protocol conformances; this is easily resolved.
This fixes the crash in SR-10926 (rdar://51710424). The obscurity of this crash --- which originally made us think it might be related to Error self-conformance --- is because it is only triggered when a function signature takes advantage of a concrete-but-dependent retroactive conformance, which (to be both concrete and dependent) must furthermore be conditional. Testing the other cases besides a root conformance requires an even more obscure testcase.
This just eliminates -enable-sil-ownership from all target-swift-frontend and
target-swift-emit-silgen RUN lines. Both of those now include
enable-sil-ownership in their expansion.
New(er) grammar:
// same module as conforming type, or non-unique
protocol-conformance-ref ::= protocol 'HP'
// same module as protocol
protocol-conformance-ref ::= protocol 'Hp'
// retroactive
protocol-conformance-ref ::= protocol module
We don't make use of this distinction anywhere yet, but we could in
the future.
Previously, the mangler searched for retroactive conformances in /any/
of a generic type's substitutions, but really we only care about the
ones that affect the generic type's conformance, i.e. those that
affect generic parameters. Refining this results in shorter mangled
names involving instantiations of generic types.
Follow-up work for rdar://problem/46735592
Fix to 510b64fcd5. The mangling operator "HP" has to distinguish
between "protocol" and "protocol module", not between the presence
or absence of protocol-conformance-ref. New grammar:
protocol-conformance-ref ::= protocol
protocol-conformance-ref ::= protocol module 'HP'
rdar://problem/46735592, again
Change the retroactive conformance mangling to use the new
any-protocol-conformance mangling, which maintains more information about
concrete conformances. Specifically, it maintains conformance information
for conditional requirements. It also uses the protocol-conformance-ref
production that will eventually allow symbolic references to protocol
conformance descriptors.
While here, extend the “is retroactive” check during mangling to look for
retroactive conformances in the conditional requirements of a conformance.
The immediate conformance might not be retroactive, but its specialization
might depend on a retroactive conformance. Mangle these as “retroactive”, so
we can correctly reconstruct the exact type.
The SILGen testsuite consists of valid Swift code covering most language
features. We use these tests to verify that no unknown nodes are in the
file's libSyntax tree. That way we will (hopefully) catch any future
changes or additions to the language which are not implemented in
libSyntax.
A "retroactive" protocol conformance is a conformance that is provided
by a module that is neither the module that defines the protocol nor
the module that defines the conforming type. It is possible for such
conformances to conflict at runtime, if defined in different modules
that were not both visible to the compiler at the same time.
When mangling a bound generic type, also mangle retroactive protocol
conformances that were needed to satisfy the generic requirements of
the generic type. This prevents name collisions between (e.g.) types
formed using retroactive conformances from different modules. The
impact on the size of the mangling is expected to be relatively small,
because most conformances are not retroactive.
Fixes the ABI part of rdar://problem/14375889.
