A regular type.subst() is not enough, because tentative type witnesses may contain type parameters,
and we have to substitute them as well, recursively, e.g A := G<B>, B := G<C>, C := Never. Avoiding
subst() here also eliminates a use case of the getSubstOptionsWithCurrentTypeWitnesses() hack.
Since we collect same-type constraints by scanning requirement signatures,
the type witness system must be prerared to face conflicting solutions
for a particular type witness
When emitting a diagnostic, mark the TypeRepr as invalid and
return an ErrorType to ensure that the diagnostic is not
emitted again, and to muffle downstream diagnostics.
Returning a null GenericSignature is not the right way to break a cycle,
because then callers have to be careful to handle the case of a null
GenericSignature together with a non-null GenericParamList, for example
in applyGenericArguments().
An even worse problem can occur when a GenericSignatureRequest for a
nested generic declaration requests the signature of the parent context,
which hits a cycle. In this case, we would build a signature where
the first generic parameter did not have depth 0.
This makes the requirement machine upset, so this patch implements a new
strategy to break such cycles. Instead of returning a null
GenericSignature, we build a signature with the correct generic
parameters, but no requirements. The generic parameters can be computed
just by traversing GenericParamLists, which does not trigger more
GenericSignatureRequests, so this should be safe.
The following regression test added for this feature is not passing:
Swift(linux-x86_64) :: decl/protocol/protocols_with_self_or_assoc_reqs_executable.swift
with a compiler crash happening during SILFunctionTransform "Devirtualizer".
Reverting to unblock CI.
This reverts commit f96057e260, reversing
changes made to 3fc18f3603.
If we don't set this flag, we can end up making an invalid GSB into
the canonical builder for some signature. This was caught by
requirement machine cross-checking on the compiler_crashers suite.
Associated type inference will synthesize typealiases in
constrained extensions for conditional conformances, but
then we might later flag them as re-declarations.
Let's not do this, since name lookup does check if generic
requirements are satisfied, so such redeclarations are not
in fact erroneous.
Fixes <rdar://problem/68933045>.
While we're here, remove the return on a null generic signature. The request for
the generic signature of a protocol is a trivial computation that is never expected
to fail
RequirementEnvironment wasn't prepared to handle a protocol
requirement with additional 'where' clause constraints but
no generic parameters.
Since such a requirement necessarily runs afoul of the existing
"protocol requirements cannot constrain Self" rule, it suffices
to ignore such requirements when matching witnesses and let
the declaration checker diagnose this situation later.
Fixes <rdar://problem/61876053>.
In the included test case, conformance checking of Wrapper : B would
pick up typealias Foo as a witness for the associated type B.Foo.
However, this typealias Foo is defined in a constrained extension where
T : A, and the underlying type references the associated type A.Foo
on T.
The resulting substitution is invalid when the conformance Wrapper : B
is used in a context where T does not conform to A.
Instead, we should ignore this typealias entirely, since it appears
in an unusable constrained extension.
Fixes <rdar://problem/60219705>, <https://bugs.swift.org/browse/SR-12327>,
<https://bugs.swift.org/browse/SR-12663>.
We should allow an associated type's default to reference the
same associated type with a base other than 'Self'.
Note that it now becomes easier to defeat this check, but it
was never air-tight anyway -- for example, you could have a
cycle of length two if each associated type's default was the
other associated type.
This is fine, because this check is purely 'cosmetic'; nothing
goes really wrong if you have a cycle here, except that the
diagnostic shifts from the declaration of the protocol to the
conforming type.
Fixes <rdar://problem/62355224>.
In `ConstraintGenerator::visitDeclRefExpr` instead of using
`getInterfaceType()` for unknown type and later mapping it into
context, let's use `getType()` which does that interally, that
allows to detect presence of error types in resulting type and
abort constraint generation.
If the setter conflict occurs in a deserialized declaration, the parent
pattern binding can be NULL. Guard the fixit on the existence of the
pattern binding so
1) we don't crash
2) we don't try to emit a fixit in otherwise extremely broken code
rdar://56558082
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>.
* [Typechecker] Allow enum cases without payload to witness a static get-only property with Self type protocol requirement
* [SIL] Add support for payload cases as well
* [SILGen] Clean up comment
* [Typechecker] Re-enable some previously disabled witness matching code
Also properly handle the matching in some cases
* [Test] Update typechecker tests with payload enum test cases
* [Test] Update SILGen test
* [SIL] Add two FIXME's to address soon
* [SIL] Emit the enum case constructor unconditionally when an enum case is used as a witness
Also, tweak SILDeclRef::getLinkage to update the 'limit' to 'OnDemand' if we have an enum declaration
* [SILGen] Properly handle a enum witness in addMethodImplementation
Also remove a FIXME and code added to workaround the original bug
* [TBDGen] Handle enum case witness
* [Typechecker] Fix conflicts
* [Test] Fix tests
* [AST] Fix indentation in diagnostics def file
