If a constraint has fully resolved but incorrect (not simplifiable)
dependent member types, let's diagnose that as a contextual mismatch
instead of failing (which sometimes leads to a fallback diagnostic).
Resolves: rdar://101412179
* Issue-60730: Addressing the situation where we were saying that (any P)? does not conform to P, instead we should offer the Force Optional error messaging
* Issue-60730: Removing assigned of AllowArgumentMismatch fix that would get thrown away if we fall into ForceOptional fix
* Issue-60730: Removing file that was accidentally changed
* Issue-60730: Updating to use simplifyConformsToConstraint - and to clean up code per comments
* Issue-60730: Updating to pass protocoDecl instead of type2 to simplifyConformsToConstraint
* Issue-60730: Updating to pass protocoDecl instead of type2 to simplifyConformsToConstraint
* Issue-60730: Updating to not pass 1 to recordFix, where that is the default value
* Issue-60730: Adding in test to validate that the fix works as expected
* Issue-60730: Cleaning up test based on PR Comments
* Issue-60730: Correcting typo in test
* Issue-60730: Adding additional test cases for layers of optionals and for non-conforming argument
* Issue-60730: Updating test to include fixme(diagnostics) for multilpe layers of force unwrap
Reference to `$geneator.next` in for-in loop context needs to be
treated as a reference to a witness of `IteratorProtocol#next`
requirement, otherwise it could lead to problems with retroactive
conformances.
Reference to `makeIterator` in for-in loop context needs to be
treated as a reference to a witness of `Sequence#makeIterator`
requirement, otherwise it could lead to problems with retroactive
conformances.
Implicit conversion used to erase path for contextual type conversions
but it does so no longer, this means that invalid initializer reference
check needs to know about existence of implicit conversions that are
not reflected in the AST until solution is applied.
Resolves: rdar://99352676
Leading-dot syntax allows implicitly unwrapping result type to form
a base type of the call, `getOpenedResultBuilderTypeFor` needs to
account for that.
Resolves: https://github.com/apple/swift/issues/60586
These will never appear in the source language, but can arise
after substitution when the original type is a tuple type with
a pack expansion type.
Two examples:
- original type: (Int, T...), substitution T := {}
- original type: (T...), substitution T := {Int}
We need to model these correctly to maintain invariants.
Callers that previously used to rely on TupleType::get()
returning a ParenType now explicitly check for the one-element
case instead.
If the failure is not reflected in constraint system it would let
the solver to form a _valid_ solution as if the constraint between
the type variable and the unresolved dependent member type never
existed.
Resolves: https://github.com/apple/swift/issues/60649
The outermost wrapper is the one at index `0` in the wrapper list
but it's easy for humans to make a reverse assumption since outermost
is the back of the list. Let's add a dedicated method to reduce error
probability of the property wrapper APIs.
Previously we relied on `TupleTypeElt::getType`
returning an `InOutType` to fail the tuple type
matching logic. Instead, add logic to reject any
inout arguments up-front with a more specific
diagnostic.
Also, while we're here, strip the `_const`
parameter flag, as it's not something that needs
to be considered for tuple construction.
Move off `Type` based requests and onto `Decl`
based requests, utilizing name lookup's
`extractDirectlyReferencedNominalTypes` utility.
This allows us to better cache the results, and
avoids the need to guard against type variable
inputs when deciding whether or not to cache.
