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.
This helps to propagate types bi-directionally and avoid extraneous
failures related to generic parameter inference when the real issue
is mutability or type erasure.
In #65125 (and beyond) `matchTypes`, has logic to attempt to wrap an
incoming parameter in a tuple under certain conditions that might help
with type expansion.
In the case the incoming type was backed by a `var`, it would be wrapped
by an `LValueType` then be subsequently mis-diagnosed as not-a-tuple.
More details in #85924 , this this is also the cause of (and fix for)
#85837 as well...
Impact for an unknown property access was frequently higher than other options
on ambiguous selections, by 3 to 5 points, causing fix selections that were
farther away and frequently noted to be in accurate. This commit lowers the
impact to be in a similar range to other fixes and this causes property accesses
to be selected more proprotionaly.
In the existing test suite, this changed the diagnostic only in the case of
protocol composition, which was also discovered to be a flawed binding lookup.
Tests added for the property lookup, tests updated for protocol composition
(Including correcting a likely error in a test specification)
If arguments are represented by a single tuple it's possible
that the issue is not about missing parameters but instead
about tuple destructuring. Fix `fixMissingArguments` to check for
overruns after destructuring and stop if that produces more
arguments then parameters because such situations are better
diagnosed as a general conversion failure rather than a missing
argument(s) problem.
Resolves: rdar://159408715
Make sure we don't produce unnecessary diagnostics while still allowing
things like cursor info to work. No test change since it's covered by
the next commit.
We know this is where the issue is so we can immediately bind to a hole,
ensuring we don't produce unnecessary downstream diagnostics from
things we can't infer.
Artem Chikin
Aviva
Pavel Yaskevich
Slava Pestov
Aviva Ruben
Pavel Yaskevich
Hamish Knight
elsa
Elsa Keirouz
Anthony Latsis
Joe Groff
Kathy Gray
Chris Williams