The maybeResolveEquivalenceClass() method can deallocate equivalence
classes, because it calls updateNestedTypeForConformance(), which
calls addSameTypeRequirement().
Therefore, the EquivalenceClass stored inside a ResolvedType could
become invalid across calls to maybeResolveEquivalenceClass().
This was a problem in one place in particular, when adding a new
same-type constraint between two type parameters.
Fix this by not caching the equivalence class of a PotentialArchetype
in the ResolvedType implementation. The only time an equivalence class
is now stored is when returning an unresolved type, which is acted
upon immediately.
Fixes <https://bugs.swift.org/browse/SR-12812>, <rdar://problem/63422600>.
- Handle cases where getArgumentLabelLocs().size() == 0
- Add some assertions to verify invariants
- Explicit handling of 'llvm::Optional' for 'getUnlabeledTrailingClosureIndex()'
- Avoid walking into nodes after the removing happens
rdar://problem/65556791
The Space Engine maintains as one of its invariants that the AST it is
handed must at least typecheck. When swift typechecks patterns, the only
case one is allowed to form a Boolean pattern is when a literal is
expected, and the corresponding type of the pattern clause is exactly
Bool. This precludes the use of other types, including
ExpressibleByBooleanLiteral types, from matching. Thus, this code path
was never hit. That is, until we accidentally lifted the restriction on
enum case base name overloading too early. Now, it is possible for the
space engine to see the same constructor head that has subspaces with
different argument types. The space engine is relatively tolerant of
this bizarre situation, but in this one narrow case it was not.
This patch has a narrow fix to add the missing case to the
space engine. In the long term, we need to actually finish SE-0155 which
will make this crash structurally impossible once again.
Resolves rdar://65229620
Previously, when an attempt was made to instantiate a generic metadata
whose argument was constrained to subclass a superclass Super with an
existential type E that had a superclass constraint to a subclass Sub of
that same superclass Super, the instantiation would fail at runtime,
despite the fact that the generic instantiation was allowed to
type-check.
The result was a runtime failure to instantiate generic metadata
resulting eventually in a crash.
Here, handling for that situation is added. When checking generic
requirements at runtime, when a superclass requirement is encountered,
an existential type is checked for. If that existential type has a
superclass constraint and if that superclass constraint is a subclass of
the superclass requirement, the check is determined to be satisfactory.
rdar://problem/64672291
Clean up a few general patterns that are now obviated by canImport
This aligns more generally with the cleanup that the Swift Package
Manager has already done in their automated XCTest-plumbing tool in
apple/swift-package-manager#1826.
The default C++ object constructor assigns the newly created object out of the function so, it should not return a value. Returning a value will trigger SILGen assertions.
Under certain circumstances, introducing a concrete same-type or
superclass constraint can re-introduce conformance constraints
which were previously redundant.
For example, consider this code, which we correctly support today:
protocol P {
associatedtype T : Q
}
protocol Q {}
class SomeClass<U : Q> {}
struct Outer<T> where T : P {
func inner<U>(_: U) where T == SomeClass<U>, U : Q {}
}
The constraint 'T == SomeClass<U>' makes the outer constraint
`T : P' redundant, because SomeClass already conforms to P.
It also introduces an implied same-type constraint 'U == T.T'.
However, whereas 'T : P' together with 'U == T.T' make 'U : Q'
redundant, the introduction of the constraint 'T == SomeClass<U>'
removes 'T : P', so we re-introduce an explicit constraint 'U : Q'
in order to get a valid generic signature.
This code path did the right thing for constraints derived via
concrete same-type constraints, but it did not handle superclass
constraints.
As a result, this case was broken:
struct Outer<T> where T : P {
func inner<U>(_: U) where T : SomeClass<U>, U : Q {}
}
This is the same example as above, except T is related via a
superclass constraint to SomeClass<U>, instead of via a concrete
same-type constraint.
The subtlety here is that we must check if the superclass type
actually conforms to the requirement source's protocol, because it
is possible to have a superclass-constrained generic parameter
where some conformances are abstract. Eg, if SomeClass did not
conform to another protocol P2, we could write
func foo<T, U>(_: T, _: U) where T : SomeClass<U>, T : P2 {}
In this case, 'T : P2' is an abstract conformance on the type 'T'.
The common case where this would come up in real code is when you
have a class that conforms to a protocol with an associated type,
and one of the protocol requirements was fulfilled by a default in
a protocol extension, eg:
protocol P {
associatedtype T : Q
func foo()
}
extension P {
func foo() {}
}
class ConformsWithDefault<T : Q> : P {}
The above used to crash; now it will type-check correctly.
Fixes <rdar://problem/44736411>, <https://bugs.swift.org/browse/SR-8814>..
Nate Cook
Augusto Noronha
Mishal Shah
Andrew Trick
Butta
Slava Pestov
Rintaro Ishizaki
Nate Chandler
Saleem Abdulrasool
Robert Widmann
Dmitri Gribenko
swift-ci
nate-chandler
Anthony Latsis
Holly Borla
Onyekachi Ezeoke
Xi Ge
zoecarver
Karoy Lorentey