Add a cached request to perform pattern resolution.
This is needed to prevent the constraint system
from resolving the same pattern multiple times
along different solver paths, which could result
in creating different pattern nodes for each path.
Once pattern resolution is moved to pre-checking
we ought to be able to make this uncached.
rdar://128661960
Although inference doesn't allow direct bindings to
type variables, they can still get through via `matchTypes`
when type is a partially resolved pack expansion that simplifies
down to a type variable.
Handle requirement failures in result builder `build*` methods explicitly
and give them a high impact rating because issues if such positions
imply that the transform didn't work and it shouldn't shadow errors
in user code.
Resolves: rdar://111120803
Resolves: rdar://120342129
If root type of a key path has been determined to be a hole there
is no reason to delay the inference decision which should be a
failure because none of the components would be inferrable from
a placeholder root.
If array literal type is not delayed and doesn't have any type variables
associated with it, let's prefer it over a disjunction to facilitate
type propagation through its `Element` type to element expressions.
Resolves: rdar://118993030
If key path type has bindings and is no longer delayed it means
that it's fully resolved and ready to be bound (even though value
type might not be resolved yet).
Produce a tailored diagnostic that omits a fully unresolved key path
type (`KeyPath<_, _>`) when key path without an explicit root type is
passed as an argument to non-keypath parameter type (i.e. `Int`).
A type variable that represents a key path literal cannot be bound
directly to `AnyKeyPath` or `PartialKeyPath`, such types could only
be used for conversions.
It used to be the task of the binding inference to infer `AnyKeyPath`
and `PartiaKeyPath` as a `KeyPath` using previously generated type
variables for a root and value associated with key path literal
(previously stored in the locator).
Recently we switched over to storing key path information in the
constraint system and introduced `resolveKeyPath` method to gain
more control over how key path type variable gets assigned.
Getting information from the constraint system creates a problem
for the inference because "undo" for some bindings would be run
after solver scope has been erased, so instead of modifying bindings
in `inferFromRelational`, let's do that in `resolveKeyPath` right
before the key path type variable gets bound which seems to be a
better place for that logic anyway.
Resolves: rdar://113760727
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
If type variable we are about to bind represents a pack
expansion type, allow the binding to happen regardless of
what the \c type is, because contextual type is just a hint
in this situation and type variable would be bound to its
opened type instead.
Resolves: rdar://112617922
`same-shape` mismatch detection logic shouldn't expect that types are
always packs because they could be either invalid (i.e. Void) or pack
archetypes too.
Resolves: rdar://112090069
Previously we would wait until CSApply, which
would trigger their type-checking in
`coercePatternToType`. This caused a number of
bugs, and hampered solver-based completion, which
does not run CSApply. Instead, form a conjunction
of all the ExprPatterns present, which preserves
some of the previous isolation behavior (though
does not provide complete isolation).
We can then modify `coercePatternToType` to accept
a closure, which allows the solver to take over
rewriting the ExprPatterns it has already solved.
This then sets the stage for the complete removal
of `coercePatternToType`, and doing all pattern
type-checking in the solver.
We shouldn't be allocating placeholders for type
variables in the permanent arena, and we should be
caching them such that equality works.
To achieve this, we need to introduce a new
"solver allocated" type property. This is required
because we don't want to mark placeholder types
with type variable originators as themselves having
type variables, as it's not part of their structural
type. Also update ErrorType to use this bit, though
I don't believe we currently create ErrorTypes
with type variable originators.
Rather than eagerly binding them to holes if the
sequence element type ends up being Any, let's
record the CollectionElementContextualMismatch fix,
and then if the patterns end up becoming holes,
skip penalizing them if we know the fix was
recorded. This avoids prematurely turning type
variables for ExprPatterns into holes, which
should be able to get better bindings from the
expression provided. Also this means we'll apply
the logic to non-Any sequence types, which
previously we would give a confusing diagnostic
to.
Only fully resolved substitutions are eligible to be considered
as conflicting, if holes are involved in any position that automatically
disqualifies a generic parameter.
Resolves: rdar://108534555
Resolves: https://github.com/apple/swift/issues/63450
Code like that is usually indicative of programmer error, and does not
round-trip through module interface files since there is no source
syntax to refer to an outer generic parameter.
For source compatibility this is a warning, but becomes an error with
-swift-version 6.
Fixes rdar://problem/108385980 and https://github.com/apple/swift/issues/62767.
Follow-up to https://github.com/apple/swift/pull/65048
`getDesugaredType` unwraps sugar types that appear in sequence,
to remove sugar from nested positions we need to get a canonical type.
Thanks to @slavapestov for pointing it out.
Generic type aliases, unless desugared, could bring unrelated type variables
into the scope i.e. `TypeAlias<$T, $U>.Context` is actually `_Context<$U>`.
These variables could be inferrable only after the the body the closure is
solved. To avoid that, let's adjust `TypeVariableRefFinder` to desugar types
before collecting referenced type variables.
Resolves: rdar://107835060
Previously, when creating availability attributes for synthesized declarations
we would identify some set of reference declarations that the synthesized
declaration should be as-available-as. The availability attributes of the
reference declarations would then be merged together to create the attributes
for the synthesized declaration. The problem with this approach is that the
reference declarations themselves may implicitly inherit availability from their
enclosing scopes, so the resulting merged attributes could be incomplete. The
fix is to walk though the enclosing scopes of the reference declarations,
merging the availability attributes found at each level.
Additionally, the merging algorithm that produces inferred availability
attributes failed to deal with conflicts between platform specific and platform
agnostic availability. Now the merging algorithm notices when platform agnostic
availability should take precedence and avoids generating conflicting platform
specific attributes.
Resolves rdar://106575142
Current logic attempts simplification of the base type only if it's
a type variable or a dependent member type. That's valid for correct
code but not for invalid code e.g. `(($T) -> Void).Element` is not
going to be simplified even if `$T` is bound, which causes crashes
in diagnostic mode because `matchTypes` is going to re-introduce
constraint with partially resolved dependent member types and by
doing so make it stale forever which trips constraint system state
verification logic.
Resolves: rdar://105149979
Introduce SingleValueStmtExpr, which allows the
embedding of a statement in an expression context.
This then allows us to parse and type-check `if`
and `switch` statements as expressions, gated
behind the `IfSwitchExpression` experimental
feature for now. In the future,
SingleValueStmtExpr could also be used for e.g
`do` expressions.
For now, only single expression branches are
supported for producing a value from an
`if`/`switch` expression, and each branch is
type-checked independently. A multi-statement
branch may only appear if it ends with a `throw`,
and it may not `break`, `continue`, or `return`.
The placement of `if`/`switch` expressions is also
currently limited by a syntactic use diagnostic.
Currently they're only allowed in bindings,
assignments, throws, and returns. But this could
be lifted in the future if desired.
It's ok to drop the global-actor qualifier `@G` from a function's type if:
- the cast is happening in a context isolated to global-actor `G`
- the function value will not be `@Sendable`
- the function value is not `async`
It's primarily safe to drop the attribute because we're already in the
same isolation domain. So it's OK to simply drop the global-actor
if we prevent the value from later leaving that isolation domain.
This means we no longer need to warn about code like this:
```
@MainActor func doIt(_ x: [Int], _ f: @MainActor (Int) -> ()) {
x.forEach(f)
// warning: converting function value of type '@MainActor (Int) -> ()' to '(Int) throws -> Void' loses global actor 'MainActor'
}
```
NOTE: this implementation is a bit gross in that the constraint solver
might emit false warnings about casts it introduced that are actually
safe. This is mainly because closure isolation is only fully determined
after constraint solving. See the FIXME's for more details.
resolves rdar://94462333
In some situations `getContextualType` for a contextual type
locator is going to return then empty type. This happens because
e.g. optional-some patterns and patterns with incorrect type don't
have a contextual type for initialization expression but use
a conversion with contextual locator nevertheless to indicate
the purpose. This doesn't affect non-ambiguity diagnostics
because mismatches carry both `from` and `to` types.
Resolves: rdar://problem/103739206
