A substitution map might store an abstract conformance even if the
replacement type is an archetype that conforms concretely via a
superclass requirement.
This is because when we build the substitution map, if the archetype
is represented by a type parameter, we don't have enough information
to know if it will conform abstractly or concretely.
We need a substitution map written in terms of the base requirement's signature;
getProtocolSubstitutions() alone was not enough because it does not include
the extra generic parameters that the base requirement might have if it is
itself generic.
Rework Sendable checking to be completely based on "missing"
conformances, so that we can individually diagnose missing Sendable
conformances based on both the module in which the conformance check
happened as well as where the type was declared. The basic rules here
are to only diagnose if either the module where the non-Sendable type
was declared or the module where it was checked was compiled with a
mode that consistently diagnoses `Sendable`, either by virtue of
being Swift 6 or because `-warn-concurrency` was provided on the
command line. And have that diagnostic be an error in Swift 6 or
warning in Swift 5.x.
There is much tuning to be done here.
Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
* Initial draft of async sequences
* Adjust AsyncSequence associated type requirements
* Add a draft implementation of AsyncSequence and associated functionality
* Correct merge damage and rename from GeneratorProtocol to AsyncIteratorProtocol
* Add AsyncSequence types to the cmake lists
* Add cancellation support
* [DRAFT] Implementation of protocol conformance rethrowing
* Account for ASTVerifier passes to ensure throwing and by conformance rethrowing verifies appropriately
* Remove commented out code
* OtherConstructorDeclRefExpr can also be a source of a rethrowing kind function
* Re-order the checkApply logic to account for existing throwing calculations better
* Extract rethrowing calculation into smaller functions
* Allow for closures and protocol conformances to contribute to throwing
* Add unit tests for conformance based rethrowing
* Restrict rethrowing requirements to only protocols marked with @rethrows
* Correct logic for gating of `@rethrows` and adjust the determinates to be based upon throws and not rethrows spelling
* Attempt to unify the async sequence features together
* Reorder try await to latest syntax
* revert back to the inout diagnosis
* House mutations in local scope
* Revert "House mutations in local scope"
This reverts commit d91f1b25b59fff8e4be107c808895ff3f293b394.
* Adjust for inout diagnostics and fall back to original mutation strategy
* Convert async flag to source locations and add initial try support to for await in syntax
* Fix case typo of MinMax.swift
* Adjust rethrowing tests to account for changes associated with @rethrows
* Allow parsing and diagnostics associated with try applied to for await in syntax
* Correct the code-completion for @rethrows
* Additional corrections for the code-completion for @rethrows this time for the last in the list
* Handle throwing cases of iteration of async sequences
* restore building XCTest
* First wave of feedback fixes
* Rework constraints checking for async sequence for-try-await-in checking
* Allow testing of for-await-in parsing and silgen testing and add unit tests for both
* Remove async sequence operators for now
* Back out cancellation of AsyncIteratorProtocols
* Restructure protocol conformance throws checking and cache results
* remove some stray whitespaces
* Correct some merge damage
* Ensure the throwing determinate for applying for-await-in always has a valid value and adjust the for-await-in silgen test to reflect the cancel changes
* Squelch the python linter for line length
If the substituted type for a conformance found via a superclass constraint is a subclass of that
superclass, then we should represent that with an InheritedProtocolConformance rather than with
the original root conformance that applies to the superclass. If we don't do this, then we end up
with spurious inequalities in generic signatures that ought to be equivalent, because some
paths use the inherited conformance and some don't, as in SR-12330 | rdar://problem/60174186.
Motivation: `GenericSignatureImpl::getCanonicalSignature` crashes for
`GenericSignature` with underlying `nullptr`. This led to verbose workarounds
when computing `CanGenericSignature` from `GenericSignature`.
Solution: `GenericSignature::getCanonicalSignature` is a wrapper around
`GenericSignatureImpl::getCanonicalSignature` that returns the canonical
signature, or `nullptr` if the underlying pointer is `nullptr`.
Rewrite all verbose workarounds using `GenericSignature::getCanonicalSignature`.
There's an evolution proposal going through that allows
for this in more places, so let's fix a known bug in this
area.
Fixes <https://bugs.swift.org/browse/SR-10073>,
<rdar://problem/48925725>.
Use ProtocolConformanceRef::forInvalid() in implementations only as a semantic signal. In one place, use the default constructor to drop the final use of Optional<ProtocolConformanceRef>.
ProtocolConformanceRef already has an invalid state. Drop all of the
uses of Optional<ProtocolConformanceRef> and just use
ProtocolConformanceRef::forInvalid() to represent it. Mechanically
translate all of the callers and callsites to use this new
representation.
Structurally prevent a number of common anti-patterns involving generic
signatures by separating the interface into GenericSignature and the
implementation into GenericSignatureBase. In particular, this allows
the comparison operators to be deleted which forces callers to
canonicalize the signature or ask to compare pointers explicitly.
Note that while the original crasher in the radar is gone, my reduced test
case triggers an IRGen crash on both 5.1 and master because of an unrelated
bug that appears to be related to protocol requirement signatures and
declaration ordering.
Fixes <rdar://problem/54952911>.
We've fixed a number of bugs recently where callers did not expect
to get a null Type out of subst(). This occurs particularly often
in SourceKit, where the input AST is often invalid and the types
resulting from substitution are mostly used for display.
Let's fix all these potential problems in one fell swoop by changing
subst() to always return a Type, possibly one containing ErrorTypes.
Only a couple of places depended on the old behavior, and they were
easy enough to change from checking for a null Type to checking if
the result responds with true to hasError().
Also while we're at it, simplify a few call sites of subst().
Do a weaker check here that only looks at the canonical generic params
and guarantees that *those* substitute to themselves. There may be
replacement types for other generic params too, to canonicalize them,
but that's not a problem.
This fixes a crash trying to mangle decls with opaque result types
that have generic signatures that canonicalize away a generic
parameter.
rdar://problem/51775857
ConformanceChecker::ensureRequirementsAreSatisfied() modifies the
conformance as it resolves each one of its associated conformances,
so a re-entrant call can end up corrupting state by adding too
many elements to the buffer, or adding elements at the wrong
offsets.
If TypeChecker::checkConformanceRequirements() was called before
ConformanceChecker::resolveTypeWitnesses(), we could re-entrantly call
ConformanceChecker::ensureRequirementsAreSatisfied():
TypeChecker::checkConformanceRequirements()
=> ConformanceChecker::ensureRequirementsAreSatisfied()
=> Type::subst(), etc
=> ConformanceChecker::resolveTypeWitnesses()
=> ConformanceChecker::ensureRequirementsAreSatisfied()
The code in SubstitutionMap::lookupConformance() worked around
this by checking the failure condition and calling
resolveTypeWitness() first, before calling getAssociatedConformance().
Instead, remove this and call resolveTypeWitness() from inside
NormalProtocolConformance::getAssociatedConformance().
When looking up a conformance in a substitution map, check whether
there is a superclass constraint that satisfies the conformance. If
so, use it directly rather than going through a slower path to find
it.
Addresses rdar://problem/46655186.
