The previous logic was relying on doing `coerceCallArguments` with the
full argument list instead of only the non-trailing args, and wasn't
handling the non-shorthand-init case. Update the logic to fix-up the
apply during the pre-walk, ensuring it gets applied consistently.
rdar://170076966
These will be used internally by the type checker to represent bindings
that are the joins and meets of types involving type variables. They
will not appear anywhere outside of the bindings code---so you won't
see them in expressions, or matchTypes(), etc.
A type variable that represents the type of a closure can only be bound
to a function type, but this fact is not directly encoded in the
constraint system.
Check for the appearance of a non-sensical subtype binding on a closure
type variable in reduceBinding(), and promote the binding to exact as
soon as we detect this, since binding the type will always fail; we want
to fail as quickly as possible, before attempting any more disjunctions.
This is a generally good performance optimization, and it also addresses
a performance regression from "Sema: Filter bindings by considering
conformance constraints".
This also speeds up the expression from rdar://59008707, which also uses
Combine and is slow for similar reasons.
If common result type optimization binds the type variable
representing the member chain result before we attempt an
overload from the corresponding disjunction, the
UnresolvedMemberChainBase constraint would fail.
The specific situation this would occur was when the extension
declared overloaded members with a concrete return type instead
of Self, and then this method was part of a chain:
extension P where Self == S {
func f(_: Int) -> S { ... }
func f(_: String) -> S { ... }
func g()
}
... foo(.f(3).g()) ...
The TestNoDoubleVoidClosureResultInference were actually not
exercising the code path they were supposed to because we
didn't check for that locator kind in getImpliedResultConversionKind().
Code with Protocol Composition parameters had not been taking into account
that a parameter would conform to all protocols in the composition on
member resolution and could fail to find a member for one protocol
on static lookups, resulting in a diagnostic that was incorrect even on
correct programs.
For example
```protocol P {
static var boo
}
protocol Q {
}
func t<T: P&Q>(x: T) { }
t(.boo)```
Diagnostic of Q does not have member boo
(Yes, other diagnostics are required in this code)
This occured because P and Q were considered one path at a time.
After the change, the P&Q path is considered together instead.
This replaces #87114, aligning the `BorrowingSequence` protocols and
related types to the Swift Evolution proposal, and without included
reparenting of `Sequence`.
If a partial application captures any non-`SendableMetatype` type parameter,
then it can call methods that are isolated to the current context and so the
function value cannot be `@Sendable`.
Resolves: rdar://170475422
Instead of SK_Unavailable.
This is so that test/Constraints/rdar139812024.swift will continue to
pass with an upcoming change. The problem was that in this test,
an unsound optimization meant that we would find a worse solution,
by not considering the better solution, according to our scoring
rules. The worse solution involved an unavailable conformance to
Sendable, while the better one used a missing synthesized one.
Note that this is only an issue in Swift 5 mode, where unavailable
Sendable conformance is a warning. Both are an error in Swift 6 mode,
so it doesn't matter which solution we pick there anyway.
Introduce new syntax for parsing arbitrary integer literal expressions for generic value arguments:
```swift
InlineArray<(<Expr>), T>
[(<Expr>) of T]
```
Which, for now, will co-exist alongside the current syntax of simple integer literals.
Replace `IntegerTypeRepr` with `GenericArgumentExprTypeRepr`, a new `TypeRepr` node that wraps arbitrary expressions in generic argument positions (e.g., `InlineArray<(1 + 3), Int>`). The node tracks resolution state, distinguishing whether the expression resolved to a type or an integer value.
Key changes:
- Parse parenthesized generic arguments as expressions
- Recover and distinguish types from integer expressions in `resolveGenericArgumentExprTypeRepr`.
- When the `LiteralExpressions` feature is enabled, type-check and constant-fold expressions to integer values
- Extract `PreCheckTarget` into a public header to expose `simplifyTypeExpr` for use during type resolution
Resolves rdar://168005391
Fixes#69245 by ensuring CSSimplify does not wrap PackExpansionType in a
tuple when it is the argument for a tuple parameter. This was causing a
crash. Also changes matchTypes to wrap such a pack expansion in a tuple
after diagnosing so we can infer more types. Adds a tailored diagnostic,
note, and fix-it to AllowInvalidPackExpansion for tuple containing pack
expansion parameters, that wraps with parens and names tuple parameter
instead of non-pack parameter.
In a typed throws context a throwing closure (as determined from the
body or an explicit `throws`) assumes an error type of the context that
is a subtype of `any Error`.
This is a carve out from `FullTypedThrows` feature that let's more
code that adopted typed throws to type-check without source compatibility
impact since without context a closure would still be using un-typed
throws and no additional inference of error type is done.
Missed this in my original Sendable-dependence patch, the sendability
of a closure can be dependent if its contextual type is. I'm not
sure this case ever actually matters in practice, but it seems like we
ought to be consistent with the existing logic and not have the
behavior be dependent on whether the dependence is evaluated before or
after the closure is resolved.
ForEach support for Borrowing sequence
For testing purposes, this commit includes _BorrowingSequence and _BorrowingIterator protocols, with conformance for Span and InlineArray.
Still record overload choices for `makeIterator` and `next` when
solving a `ForEachElement` constraint. This maintains compatibility
with the previous behavior where we would solve these in the constraint
system, since the choices can affect ranking if e.g Collection's
default `makeIterator` is compared with a concrete `makeIterator`
overload. This is a complete hack though and we ought to rip this out
as soon as we can.
rdar://168840696
If the base captured type still has type variables when we bind the
member function type, form a Sendable dependent function type with
the base type. This will then be eliminated by TypeSimplifier once
all the type variables in the base type have been resolved.
This then allows us to remove the delaying logic from member lookup.
We no longer need to track the `ForEachStmtInfo` in the
`SyntacticElementTarget`, and we can remove the special diagnostic
logic for `next` and `makeIterator` since those are type-checked
separately now.
Hamish Knight
Slava Pestov
Alfonso Urdaneta
elsa
Kathy Gray
Elsa Keirouz
Nate Cook
Pavel Yaskevich
Pavel Yaskevich
Artem Chikin
Aviva
Aviva Ruben
Anthony Latsis
Joe Groff