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
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
We shouldn't store a pointer to the ConstraintSystem inside every
BindingSet, but there are some annoying things to untangle before
we can do that.
As a starting point toward that, remove the getConstraintSystem()
getter so that at least we can't reach up to the ConstraintSystem
from the outside.
This reverts commit 6852bc9834.
In addition to the original change, this makes sure that C++ `std::string` and Swift `String` are given distinct score, in order to prevent ambiguity which was causing build failures in some projects.
rdar://158439395
We already had bookkeeping to track which statement in a multi-statement
closure we were looking at, but this was only used for the 'reasonable time'
diagnostic in the case that we hit the expression timer, which was almost
never hit, and is now off by default. The scope, memory, and trial limits
couldn't use this information, so they would always diagnose the entire
target being type checked.
Move it up from ExpressionTimer to ConstraintSystem, so that we get the
right source location there too. Also, factor out some code duplication
in BuilderTransform to ensure we get the same benefit for result builders
applied to function bodies too.
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.
This reverts commit cd9c37ca
This is causing build failures for some projects. We need more time to investigate. Reverting this temporarily in the meantime.
rdar://158439395
Make sure we query the constraint system for a type if we have a local
property wrapper in a closure to avoid kicking interface type
computation outside the closure, and make sure we map into context if
we need to.
These methods can be simplified a bunch since the returned decl is
always the input decl and we can refactor the lambdas to just return
the auxiliary variable and have the type computation in the caller.
This test case crashes when prepared overloads are disabled, but passes
when enabled. To avoid messing up tests if we have to turn the flag on
and off, fix the crash.
Move the logic from `FailureDiagnostic::resolveType` into
`Solution::simplifyType` to allow completion to use it too. While
here, also handle cases where the placeholder is from a different
member of the equivalence class to the generic parameter.
This means we now either produce a bare ErrorType, or an ErrorType
with a generic parameter original type for a generic parameter hole.
We ought to further consolidate this logic by sinking the generic
parameter original type replacement into `simplifyType` itself, but
I'm leaving that for a future patch since it affects completion
results and I want to try keep this close to NFC.
Untyped throws depends on existentials (`any Error`), and is therefore
not available in Embedded Swift. Introduce a diagnostic that diagnoses
any use of untyped throws, suggesting that one use typed throws
instead.
Make this an opt-in diagnostic enabled with `-Wwarning
EmbeddedRestrictions`, whether in Embedded Swift or not, using the
"default ignore" flag on these new warnings. Document this new
diagnostic group, and put the existing Embedded Swift error about
weak/unowned references in it as well.
Part of the general push to have the type checker identify code that
will not compile as Embedded Swift earlier, rdar://133874555.
