This more powerful primitive is capable of
1) Detecting invalid classes
2) Detecting invalid superclasses
3) Detecting circularity in inheritance hierarchies
The attached crasher demonstrates the reason we need to validate all of these predicates. Simply put, a circular class hierarchy is always going to report the superclass conforms to any protocol with a declaration in the source. Leveraging this, one could construct any circular class hierarchy, and a conformance to Codable would immediately crash because we got as far as trying to build a CodingKeys enum with an absolutely nonsensical structure.
This also has the added benefit of de-complecting an enormous amount of codable conformance code.
rdar://66588925
We can't actually check for NaN (because the notion doesn't exist for Comparable), but we can require that the endpoint is non-exceptional by checking if it equals itself.
* [Mangling] Add a new mangling to represent opaque return type for ObjC runtime name
* [Docs] Add the new 'Qu' mangling to 'Mangling.rst' document
* [Test] Update test invocation arguments
Make sure we consistently use getParentForLookup() and not getParent()
when looking at generic DeclContexts. This is because an extension or
protocol that is nested inside of another generic context must never
inherit generic parameters from the parent context.
We already had this invariant enforced in some places, but now that we
do it more consistently we can fix more crashes of this kind.
Fixes <rdar://problem/58813746>, <https://bugs.swift.org/browse/SR-13004>.
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.
