This addresses a crash where the compiler asks if an imported class
inherits initializers from its superclass /during the SIL passes/. In
this particular arrangement of subclasses and initializers (see test
case), this leads to us importing members of an Objective-C class for
the first time well after we've destroyed the type checker, and then
checking to see if an initializer added in a Swift extension can
prevent initializer inheritance. That initializer hasn't been
type-checked (because it's in another file and isn't supposed to
affect anything), and so the compiler chokes. A spot fix would merely
check for 'resolver' here and skip over the initializer if it doesn't
have a type, but it's not clear what the right semantics are in that
case.
The real issue here is that we don't support importing new declarations
after the type checker has been torn down, and that keeps causing us
problems, but that's a much bigger thing to fix.
https://bugs.swift.org/browse/SR-3853
We must order protocol typealiases *after* other types, so that
if a protocol typealias is equal to an associated type, the
representative is chosen to be the associated type and not the
typealias.
Fixes <https://bugs.swift.org/browse/SR-3687> and
<rdar://problem/30118513>.
Now that optional payloads can be re-abstracted, there's a case
where we need to do a tuple-to-tuple conversion on a direct result;
if the result is wrapped in an Optional. So I believe this assert
is not right.
Fixes <https://bugs.swift.org/browse/SR-3706>.
The PR added a Sema test with a minimal test case; add a bigger test
more closely resembling the original snippet and make sure it gets
all the way through IRGen.
Fixes assertion failures in SILGen and the optimizer with this
exotic setup:
protocol P {
associatedtype T : Q
}
protocol Q {
func requirement<U : P>(u: U) where U.T == Self
}
Here, we only have a U : P conformance, and not Self : Q,
because Self : Q is available as U.T : Q.
There were three problems here:
- The SIL verifier was too strict in verifying the generic signature.
All that matters is we can get the Self parameter conformance, not
that it's the first requirement, etc.
- GenericSignature::getSubstitutionMap() had a TODO concerning handling
of same-type constraints -- this is the first test-case I've found
that triggered the problem.
- GenericEnvironment::getSubstitutionMap() incorrectly ignored
same-type constraints where one of the two types was a generic
parameter.
Fixes <https://bugs.swift.org/browse/SR-3321>.
In a generic signature like <T, U where T.A == U>, there is only
one primary archetype, 'T'. 'U' will not appear in SubstitutionMaps,
and the SubstitutionMap version of Type::subst() cannot handle an
interface type containing 'U'.
For interface types, there are two levels of canonicalization:
- The AST-level getCanonicalType() which strips away sugar
- The GenericSignature-level getCanonicalTypeInContext() which
replaces each interface type in an equivalence class with a
representative
SILFunctionTypes must be canonical with respect to a generic
signature.
When emitting re-abstraction thunks we could end up constructing
a SILFunctionType containing 'U', because we were calling
getCanonicalType() on the result of mapTypeOutOfContext().
Fix this by making sure to use getCanonicalTypeInContext() on
the result of mapTypeOutOfContext(), just as we do in capture
lowering.
Unfortunately I worry this problem will come up again in a
different form -- a more general fix would change
mapTypeOutOfContext() to always return "generic signature
canonical" types, and also fix SubstitutionMaps to understand
same type constraints better.
Fixes <https://bugs.swift.org/browse/SR-3326>.
Be sure to lower the payload type of UnsafeMutablePointer and friends
before converting them, because the Clang type converter expects
optionals to have lowered payloads already.
Also, remove the FunctionType path; with the above change AST-level
function types should no longer show up here.
Fixes <https://bugs.swift.org/browse/SR-2702>.
Invalid ASTs like the one in 28625 cause Parse to generate an AST that
looks a heck of a lot like a constructor call, however this makes no
sense as the type in question is a TupleType and lookup asserts in such
cases. Guard against this so we don't crash diagnosing.
- In functions called from resolveType(), consistently
use a Type() return value to indicate 'unsatisfied
dependency', and ErrorType to indicate failure.
- Plumb the unsatisfiedDependency callback through the
resolution of the arguments of BoundGenericTypes, and
also pass down the options.
- Before doing a conformance check on the argument of a
BoundGenericType, kick off a TypeCheckSuperclass request
if the type in question is a class. This ensures we don't
recurse through NominalTypeDecl::prepareConformanceTable(),
which wants to see a class with a valid superclass.
- The ResolveTypeOfDecl request was assuming that
the request was satisfied after calling validateDecl().
This is not the case when the ITC is invoked from a
recursive call to validateDecl(), hack this up by returning
*true* from isResolveTypeDeclSatisfied(); otherwise we
assert in satisfy(), and we can't make forward progress
in this case anyway.
- Fix a bug in cycle breaking; it seems if we don't invoke
the cycle break callback on all pending requests, we end
up looping forever in an outer call to satisfy().
- Remove unused TR_GlobalTypeAlias option.
This handles situation when overload for the subscript hasn't been resolved
by constraint solver, such might happen, for example, if solver was allowed to
produce solutions with free or unresolved type variables (e.g. when running diagnostics).
Resolves: <rdar://problem/27329076>, <rdar://problem/28619118>, <rdar://problem/2778734>.
This reverts commit dc24c2bd34.
Turns out Chris fixed the build but when I was looking at the bots, his fix had
not been tested yet, so I thought the tree was still red and was trying to
revert to green.
