We can fix a call of a non-function type by recording
`RemoveInvalidCall`, but may still record other fixes that want to
check whether a locator has function arg apply info associated with it.
Given the base expression can basically be any expression node in this
case, trying to assert whether or not we expect a callee locator to
be set is pretty fragile and isn't really providing any real value,
especially as it's a lowercase `assert`. Let's just drop it. We'll
bail from `getFunctionArgApplyInfo` if we don't have an actual function
type.
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.
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.
Anything that can be forward declared in ASTContext.h should be because it is
included by nearly every implementation file in the compiler. Avoiding these
includes allows these various options types to be changed without a full
rebuild.
NFC.
When the constraint solver is mid-closure and encounters a reference to
an IUO-typed local variable whose type is an unbound generic member
(e.g. `var x: G.Inner!` where `G` is `struct G<T>`), the call to
`decl->getInterfaceType()` in `OverloadChoice::getIUOReferenceKind`
triggers `InterfaceTypeRequest` -> `NamingPatternRequest` ->
`PatternBindingEntryRequest` -> `typeCheckPatternBinding`, which then
trips the assertion enforced by #85141 ("Cannot type-check
PatternBindingDecl without closure context").
A VarDecl/ParamDecl can never have an IUO-returning function type
(that spelling is only valid for funcs and subscripts), so we already
know the answer is `IUOReferenceKind::Value`. Short-circuit before
forcing the interface type.
Fixes#88530.
Code generation passes can crash if `async` is used without the
_Concurrency library present. Diagnose this in the type checker to
prevent us from going further.
Fixes issue #87068 / rdar://169919137
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
Untyped throws requires a heap allocation and reference counting for
thrown errors, which can be unacceptable in very
performancce-constrained environments. Introduce a new subgroup of
performance hints, UntypedThrows, to report uses of untyped throws.
This resurrects the code we were using for diagnosing untyped throws
in Embedded Swift, repurposing it as a performance hint, which is more
appropriate.
It is plausible that we will introduce support for untyped throws in
Embedded Swift at some point, so don't diagnose its presence so
eagerly now. Instead, leave it until later in the pipeline when it's
actually used.
Fixes rdar://162071067, where we were getting entirely too many
warnings about this.
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
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.
This optimizes for the case where we have a disjunction that contains an
operator defined in a protocol, and a protocol defined in a protocol
extension, and furthermore, the protocol extension operator's type is a
refinement of the protocol requirement operator's type.
In this case, there are three possibilities:
- Either the operator requirement is witnessed by a concrete operator
in the conforming type, in which case the solution involving the
protocol extension operator is going to be worse, so we can skip this
choice.
- Otherwise, the protocol requirement operator is witnessed by the same
protocol extension operator that we skipped, in which case we will find
the same solution if we just pick the protocol requirement operator
anyway.
- The only other possibility is that the protocol requirement operator
is witnessed by a protocol extension operator, but also, a more
refined protocol extension operator exists. However, it appears that in
this case, solution ranking _also_ picks the solution involving the
protocol requirement operator, as the new test case demonstrates.
Thus, we gain nothing by considering these protocol extension operators.
Skip them when forming the disjunction.
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 actually have to check this constraint, otherwise we accept invalid
code where we're referencing a protocol requirement with a concrete
base type which conditionally conforms to the protocol, but the
conditional requirements are unsatisfied.
However, we still need to skip it for AnyObject lookup, Distributed
Actors, and some weird edge case in conformance checking for isolated
conformances.
We should clean this up further later, but for now this closes a soundness
hole.
Fixes rdar://168129757.
IsPattern coercions aren't properly implemented since they rely on
doing a runtime cast, which can fail for things like function subtyping.
Make clients choose what behavior they want. Unfortunately we need to
preserve the current behavior in places since it's relied upon for
things like exhaustivity checking. We ought to properly implement
coercion handling, then we should be able to remove this.
Previously, `getCalleeLocator` handled `ComponentKind::Apply` by returning a locator for the current component index. This was incorrect because the callee for an application is the member being applied (the previous component), not the application itself.
This patch updates `getCalleeLocator` to use `componentElt->getIndex() - 1` for `Apply` and `UnresolvedApply` components. This ensures that the constraint system can correctly identify the callee when diagnosing argument mismatches in KeyPath expressions (e.g., `\.split(...)`), leading to correct diagnostics instead of fallback errors.
Removed null check
The compiler previously crashed (Signal 11 or assertion failure) when diagnosing missing or mismatched arguments in KeyPath expressions (e.g., `\.split(separator: ",")`). This occurred because `getCalleeLocator` did not correctly identify the underlying function (callee) for a KeyPath application component.
This change updates `getCalleeLocator` to correctly resolve the callee to the preceding component (index - 1) in the KeyPath, as suggested during review.
Additionally, this change fixes a latent crash in `getFunctionArgApplyInfo` exposed by the locator fix. Previously, that function blindly cast the anchor to `CallExpr` when no overload was found. It now safely checks via `getAsExpr<CallExpr>` and returns `nullopt` if the anchor is a `KeyPathExpr`, preventing assertion failures.
Resolves: https://github.com/swiftlang/swift/issues/85942
The compiler previously crashed (Signal 11 or assertion failure) when diagnosing missing or mismatched arguments in KeyPath expressions (e.g., `\.split(separator: ",")`). This occurred because `getCalleeLocator` did not correctly identify the underlying function (callee) for a KeyPath application component.
Previously, `getCalleeLocator` failed to resolve the `Apply` component to its corresponding member. This caused `getFunctionArgApplyInfo` to fail when attempting to retrieve the argument list and overload choice, leading to a crash during diagnostic generation.
This change updates `getCalleeLocator` to specifically handle `KeyPathComponent::Apply` and `UnresolvedApply`. It now correctly resolves the callee to the *preceding* component (index - 1) in the KeyPath, ensuring the correct overload and argument list are retrieved without collisions.
Resolves: https://github.com/swiftlang/swift/issues/85942
Fix `getCalleeLocator` to correctly return the previous component
(the callee) for KeyPath Apply components, rather than the Apply
component itself. This allows `getFunctionArgApplyInfo` to properly
retrieve overload information and avoid crashing on invalid KeyPath
expressions.
Update test expectations to match errors from the new parser.
The compiler previously crashed when diagnosing missing arguments in KeyPathExpr (e.g., \.split(separator: ",")). This occurred because getFunctionArgApplyInfo failed to handle KeyPathExpr anchors, and CSDiagnostics.cpp blindly unwrapped the result.
This change fixes the crash by:
- Retrieving KeyPath Overloads: Updating ConstraintSystem::getFunctionArgApplyInfo to scan the locator path for the KeyPathComponent. This allows us to retrieve the correct argument list and overload choice (function type) when available.
- Adding Safety Check: Updating MissingArgumentsFailure::diagnoseAsError to safely check if FunctionArgApplyInfo was successfully created before accessing it. This ensures graceful failure if the solver cannot determine the overload for the malformed component.
This patch fixes a compiler crash (Signal 11) where `getFunctionArgApplyInfo`
blindly cast an expression to `CallExpr` without verification, and
`CSDiagnostics` subsequently dereferenced a null result.
This occurred specifically when using a KeyPath expression (e.g. inside `.map`)
that had argument labels missing. The diagnostic logic triggered on the KeyPath
node, which is not a `CallExpr`, causing an assertion failure in debug builds
and a segfault in release builds.
Resolves: https://github.com/swiftlang/swift/issues/85942
Hamish Knight
Itai Ferber
Slava Pestov
Allan Shortlidge
Pavel Yaskevich
CognitiveDisson
Konrad Malawski
Alex Azarov
Pavel Yaskevich
Doug Gregor
Anthony Latsis
AnirudhMathur12