I have a lot more known-failing GSB test cases, but the limiting factor
now is the GSB's minimization algorithm, which runs first before the
requirement machine gets to see anything. Replacing that with a new
algorithm based on the rewrite system is the next step here.
Name lookup might find an associated type whose protocol is not in our
conforms-to list, if we have a superclass constraint and the superclass
conforms to the associated type's protocol.
We used to return an unresolved type in this case, which would result in
the constraint getting delayed forever and dropped.
While playing wack-a-mole with regressing crashers, I had to do some
refactoring to get all the tests to pass. Unfortuanately these refactorings
don't lend themselves well to being peeled off into their own commits:
- maybeAddSameTypeRequirementForNestedType() was almost identical to
concretizeNestedTypeFromConcreteParent(), except for superclasses
instead of concrete same-type constraints. I merged them together.
- We used to drop same-type constraints where the subject type was an
ErrorType, because maybeResolveEquivalenceClass() would return an
unresolved type in this case.
This violated some invariants around nested types of ArchetypeTypes,
because now it was possible for a nested type of a concrete type to
be non-concrete, if the type witness in the conformance was missing
due to an error.
Fix this by removing the ErrorType hack, and adjusting a couple of
other places to handle ErrorTypes in order to avoid regressing with
invalid code.
Fixes <rdar://problem/45216921>, <https://bugs.swift.org/browse/SR-8945>,
<https://bugs.swift.org/browse/SR-12744>.
This check wasn't ever correct, because the fact that the the protocol comes
from another module doesn't change the fact that the type is valid for lookup
within this module. It incorrectly rejects the following, valid code:
```swift
// In A.swift
public protocol A {}
```
```
// In B.swift
import A
extension A {
typealias B = Int
func b(_ b: Self.B) {}
}
```
We generated a mix of "inferred" and "nested type name match"
constraints for the case where we had two nested types with the same
name and inferred that they are equal. Make them consistent by always
using nested type name match constraints. This fixes a bug where we
would get different canonical generic signatures in different source
files because we inferred the same-type constraint with different
requirement sources.
Fixes rdar://problem/48049725.
There's no way to look up information about objective-c generic
parameters, meaning the runtime cannot check same-type constraints or
conformance requirements, so dynamic casts cannot work. We want to keep
the static and dynamic systems the same, so we have to disable this
functionality from the start (i.e. no conditional conformances on
objective-c types :( ).
Fixes rdar://problem/37524969.
Previously, qualified lookup would use a metatype to signal
to the LookupResultBuilder that conformance checks should not
be used to resolve protocol members found with a concrete
type base. This is too subtle for my taste. Add an explicit
flag and clean up some usages, fixing <rdar://problem/16123805>.
Also, clean up the 'CheckProtocolMembers' flag. We now set
when the base type is an archetype, and correctly handle
the concept of an abstract conformance. This finally
fixes <rdar://problem/22776964>.
Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
