...even if the conforming nominal type is resilient. It's the owner
of the conformance whose resilience matters.
I also factored this part out into a separate check at the AST level
so we can tweak it, and also so I can use it to (slightly) speed up
compiling a resilient swiftinterface.
When determining whether a given normal protocol conformance is “retroactive”,
consider an overlay module to be equivalent to its underlying Clang module.
Therefore, don’t classify conformances within the overlay as “retroactive”,
simplifying some common manglings (e.g., NSObject’s Hashable conformance is
no longer considered retroactive) and better capturing the intent.
Witness table accessors return a witness table for a given type's
conformance to a protocol. They are called directly from IRGen
(when we need the witness table instance) and from runtime conformance
checking (swift_conformsToProtocol digs the access function out of the
protocol conformance record). They have two interesting functions:
1) For witness tables requiring instantiation, they call
swift_instantiateWitnessTable directly.
2) For synthesized witness tables that might not be unique, they call
swift_getForeignWitnessTable.
Extend swift_instantiateWitnessTable() to handle both runtime
uniquing (for #2) as well as handling witness tables that don't have
a "generic table", i.e., don't need any actual instantiation. Use it
as the universal entry point for "get a witness table given a specific
conformance descriptor and type", eliminating witness table accessors
entirely.
Make a few related simplifications:
* Drop the "pattern" from the generic witness table. Instead, store
the pattern in the main part of the conformance descriptor, always.
* Drop the "conformance kind" from the protocol conformance
descriptor, since it was only there to distinguish between witness
table (pattern) vs. witness table accessor.
* Internalize swift_getForeignWitnessTable(); IRGen no longer needs to
call it.
Reduces the code size of the standard library (+assertions build) by
~149k.
Addresses rdar://problem/45489388.
The former appears in the code base a lot more frequently than the
latter, which returns a GenericTypeParamType *. Use it only in places
where the more specific type is intended.
There is an invariant that SignatureConformances should have the same
size as the number of conformance requirements in the signature.
Previously, since unsatisfied requirements weren't reflected in it,
that caused a crash.
rdar://problem/43625800
In one test where we used to dump conditional requirements we now print
a message that they have not been computed yet. I couldn't come up with
a way to force them to be computed here, but for the most part this test
is just ensuring that we don't recurse forever when printing recursive
conformances.
Make sure we handle invalid extensions here, since calling
resolveExtension() won't always give us a generic signature.
This fixes a regression exposed by the next patch.
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
SIL will not generate calls to protocol requirements that override
other protocol requirements, so all of the witness table entries for
the overriding arguments are dynamically dead. Remove them from the
witness tables entirely.
Implements rdar://problem/43870489, reducing the size of the standard
library binary by 196k.
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
Use ExtensionDecl::getExtendedNominal() to wire up extensions to their
nominal types early in type checking (the bindExtensions()) operation,
rather than going through type validation to do so.
Make the TypeChecker’s name-lookup routines static, so they don’t depend
on the TypeCheck instance… except for one pesky place where we jump back
into protocol conformance checking. This is part of teasing apart the type
checker.
When we form a literal whose type is a type parameter where the literal
conformance comes from a superclass constraint of that type parameter,
make sure we can property extract the type witness we need.
Fixes SR-7551 / rdar://problem/39860617.
This doesn't fix the fundamental problem of correctly handling such cases, but
it is better than the "error message" that occurred previously:
Assertion failed: ((bool)typeSig == (bool)extensionSig && "unexpected generic-ness mismatch on conformance").
Fixes the crash rdar://problem/41281406 (that in
https://bugs.swift.org/browse/SR-6569 (rdar://problem/36068136)),
https://bugs.swift.org/browse/SR-8019 (rdar://problem/41216423) and
https://bugs.swift.org/browse/SR-7989 (rdar://problem/41126254).
Introduced during the bring-up of the generics system in July, 2012,
Substitution (and SubstitutionList) has been completely superseded by
SubstitutionMap. R.I.P.
Rather than ASTContext-allocating ConcreteDeclRef’s storage when there is a
non-empty substitution map, put the SubstitutionMap directly in the
ConcreteDeclRef. Simplify the various interfaces along the way.
Replace two prominent uses of SubstitutionList, in ConcreteDeclRef and
Witness, with SubstitutionMap. Deal with the myriad places where we
now have substitution maps and need substitution lists (or vice versa)
caused by this change.
Overall, removes ~50 explicit uses of SubstitutionList (of ~400).
Avoid storing more information than necessary in witnesses
and establishing the invariant that we only use out-of-line
storage when we require substitutions.
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.
As a minor step toward more global associated type inference,
allow tentative type witnesses to be found across a protocol
hierarchy, eliminating some recursion through associated type
inference. Fixes a recent regression in validation-test/stdlib/CollectionTypes.swift, as well as rdar://problem/36453271.
There was a path through associated type inference where we would end
up recording a type witness that contained an error, but for which we
had not reported that error, which would lead to downstream
crashes. Make sure that we reject such inferences.
And because it triggers once we fix this issue... make sure break
recursion when trying to resolve type witnesses lazily.
Fixes the crash in SR-6609 / rdar://problem/36038033, but we're still
failing to infer in those cases.
Protocol conformance records are becoming richer and more interesting;
separate out the "flags" word and add the various other fields that we
want there (is-retroactive, is-synthesized-nonunique, # of conditional
requirements).
When checking whether a particular protocol conformance satisfies all of
the protocol's requirements, we were suppressing substitution failures.
In some cases, this would mean that we marked a conformance "invalid"
without ever emitting a diagnostic, which would lead to downstream crashes.
Instead, treat substitution failures somewhat more lazily. If we encounter
one while performing the checking, put the conformance into a "delayed" list
rather than failing immediately. Teach the top-level type checking
loop to re-check these conformances, emitting a diagnostic if they
fail the second time around.
Fixes rdar://problem/35082483 and likely other issues that slipped
through the type checker or blew up in unpredictable ways.
When forming a specialized protocol conformance, we substitute into the
conditional requirements. Allow this substitution to look into the module
to find conformances, which might be required to accurately represented
the requirements. Otherwise, we can silently end up dropping them.
We should rethink this notion of eagerly substituting conditional
requirements, and consider whether clients should always handle this
substitution. For now, fixes rdar://problem/35837054.
Allow conformance lookup in module context for conditional
A while ago, we commented-out an obvious optimization when accessing the
associated types of a protocol conformance to get better coverage of the
general substitution path. Bring that code back, avoiding the creation of
substitution maps in a few cases.
When we substitute into an inherited conformance, make sure that we
follow the superclass chain from the new conforming type up to the
matching superclass *before* doing the substitution.
Fixes rdar://problem/35632543.
Substitute the type arguments of the conforming type into the conditional
requirements of the specialized conformance, so they reflect the specific
requirements of the specialized conformance.
Fixes rdar://problem/34944286.
