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
