* 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.
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
Previously only static methods found on protocols were allowed but
it is reasonable to reference a typealias to perform an implicit call
to `.init` on its underlying type.
Resolves: rdar://88513939
When `&` is misplaced it creates r-value -> l-value mismatch
in the code which is just a consequence and shouldn't be diagnosed.
Resolves: rdar://96631324
Rather than only setting the isolated-by-preconcurrency bit during
constraint application, track the closures it will be set for as part
of the constraint system and solution. Then, use that bit when
performing "strict concurrency context" checks and type adjustments,
so we don't treat an inferred-to-by-`@Sendable`-by-preconcurrency
closure in the solver as if it weren't related to preconcurrency.
Fixes the spurious warning from
https://github.com/apple/swift/issues/59910.
This avoids us having to go down the less-efficient "salvage" path when
dealing with concurrency issues. It also fixes overloading behavior
when dealing with `@preconcurrency` and `@Sendable` functions,
such as in https://github.com/apple/swift/issues/59909.
Rather than re-using `DiagnosticBehavior` to describe how a fix should
act, introduce `FixBehavior` to cover the differences between (e.g.)
always-as-awarning and downgrade-to-warning. While here, split the
`isWarning` predicate into two different predicates:
* `canApplySolution`: Whether we can still apply a solution when it
contains this particular fix.
* `affectsSolutionScore`: Whether
These two predicates are currently tied together, because that's the
existing behavior, but we don't necessarily want them to stay that way.
Instead of the `warning` Boolean threaded through the solver's
diagnostics, thread `DiagnosticBehavior` to be used as the behavior
limit. Use this for concurrency checking (specifically dropped
`@Sendable` and dropped global actors) so the solver gets more control
over these diagnostics.
This change restores the diagnostics to a usable state after the prior
change, which introduced extra noise. The only change from existing
beavior is that dropping a global actor from a function type is now
always a warning in Swift < 6. This is partly intentional, because
there are some places where dropping the global actor is well-formed.
