Adds support for `SubscriptDecl`s to fulfill `@dynamicMemberLookup`
requirements if they have additional arguments after `dynamicMember:` so
long as those arguments have default values, or are variadic.
This allows exposing values like `#function`, `#fileID`, `#line`, etc.
to dynamic member lookup.
`SubscriptDecl` exposes eligibility for `@dynamicMemberLookup`
requirements directly, so the `TypeChecker` interface for these members
can be replaced.
`SubscriptDecl`s may get checked multiple times for eligibility in
fulfilling `@dynamicMemberLookup` requirements; since the checks are
non-trivial and the result doesn't change, this eligibility can be
cached in the decl's `Bits`.
In salvage(), there is a point where we're done solving, but we haven't
yet torn down ConstraintSystem::solverState, so the trail is still
active.
It was possible to cause a change to be recorded, because of the
path compression we do in TypeVariableType::getRepresentative().
We have a similar situation where we don't want to do path compression
when we're looking up a type variable's representative in the middle
of undo(). Generalize the existing UndoActive flag to Closed, and set
it after solving in salvage() as well.
While we're here, clean up an existing place where we would check
isUndoActive() to not do that anymore, so now getRepresentative() is
the only place that checks the state of the trail.
A better cleanup would be to try to refactor or eliminate SolverState
entirely, but this fix is pretty clean.
Note that the test cases are somewhat random because the exact scenario
is hard to trigger; you need to set up an invalid expression where the
type variables are set up in just the right way so that path compression
kicks in.
- Fixes rdar://152143989.
- Fixes https://github.com/swiftlang/swift/issues/81801.
- Fixes https://github.com/swiftlang/swift/issues/84884.
- rdar://169975618 ([nonescapable] Type conversion for function types with lifetime dependencies)
- rdar://160970376 ([nonescapable] [type checker] [source compat] protocol requirements should require matching methods signatures, including @lifetime)
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
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.
In addition to the generation number, it is important to
recompute bindings when the constraint system transitions
from not doing salvage to salvage.
This fixes diagnostic regressions with an upcoming commit.
LLDB defines `lldb::private::swift::` which causes ambiguity for
lookups. Use aliases and fully qualified names to avoid the ambiguity.
This fixes some errors with building on Windows with the GNU driver.
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
We would do stuff in the case where the type variable appeared on
the right, but just drop the constraint if the type variable was
on the left. In the latter case, record it in the new
PotentialBindings::LValuesOf vector.
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
Slava Pestov
Itai Ferber
Pavel Yaskevich
CognitiveDisson
Pavel Yaskevich
Aidan Hall
Aidan Hall
Hamish Knight
Saleem Abdulrasool
Artem Chikin