Way back in Swift 1 I was trying to draw a distinction between
"overlays", separate libraries that added Swift content to an existing
Objective-C framework, and "the Swift part of a mixed-source
framework", even though they're implemented in almost exactly the same
way. "Adapter module" was the term that covered both of those. In
practice, however, no one knew what "adapter" meant. Bring an end to
this confusion by just using "overlay" within the compiler even for
the mixed-source framework case.
No intended functionality change.
Sorting of DeclContext-local protocols and conformances shouldn't ever
be necessary, because the underlying data structures that produce
these lists should be deterministic. Sorting can hide any
non-determinism, so stop doing it and we can address the underlying
nondeterminism.
NormalProtocolConformance::isRetroactive() introduces dependency on swiftClangImporter by calling ClangModuleUnit::getAdapterModule().
Do some refactoring to break the cycle.
When debugging Objective-C or C++ code on Darwin, the debug info
collected by dsymutil in the .dSYM bundle is entirely
self-contained. It is possible to debug a program, set breakpoints and
print variables even without having the complete original source code
or a matching SDK available. With Swift, this is currently not the
case. Even though .dSYM bundles contain the binary .swiftmodule for
all Swift modules, any Clang modules that the Swift modules depend on,
still need to be imported from source to even get basic LLDB
functionality to work. If ClangImporter fails to import a Clang
module, effectively the entire Swift module depending on it gets
poisoned.
This patch is addressing this issue by introducing a ModuleLoader that
can ask queries about Clang Decls to LLDB, since LLDB knows how to
reconstruct Clang decls from DWARF and clang -gmodules producxes full
debug info for Clang modules that is embedded into the .dSYM budle.
This initial version does not contain any advanced functionality at
all, it merely produces an empty ModuleDecl. Intertestingly, even this
is a considerable improvement over the status quo. LLDB can now print
Swift-only variables in modules with failing Clang depenecies, and
becuase of fallback mechanisms that were implemented earlier, it can
even display the contents of pure Objective-C objects that are
imported into Swift. C structs obviously don't work yet.
rdar://problem/36032653
If the type checker doesn't prepopulate signature conformances, fill
them in when we first need them. This is a stopgap solution until we
can move these queries over to the request-evaluator.
Fixes rdar://problem/34584596, as well as a regression introduced by
the use of mangled names for associated conformances in witness tables.
...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.
