Normally, an unbound reference to a generic type within its own context is automatically bound to the identity generic arguments:
```
struct G<T> {
typealias TA = G // as if you wrote G<T>
}
```
Module selectors normally disable this kind of contextual behavior; make sure that this is not an exception.
To pipe the information needed to do this through the constraint solver, we extend FunctionRefInfo to remember whether a module selector was used.
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 updates a large number of internal symbols, function names,
and types to match the final approved terminology. Matching the
surface language terminology and the compiler internals should
make the code easier for people to understand into the future.
If the type of a key path literal is read-only due to setter
availability constraints but the context requires a writable
key path, let's produce a tailed availability diagnostic that
points to the offending setter.
Resolves: rdar://157249275
Fixes#85376.
This fixes a compiler crash that occurred when diagnosing an ambiguous call
using trailing closure syntax, where one of the candidates was a function or
initializer with no parameters.
I missed upgrading this to an error for Swift 6 mode, let's upgrade it
to an error for a future language mode. It's important we reject these
cases since we're otherwise allowing subtyping to be a weaker constraint
than conversion.
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.
`KeyPath` types now have conformance requirements placed on their
`Root` and `Value` types which need to be checked even when there
is a key path to function conversion involved, otherwise the solver
would be accepting invalid code.
Note that without function conversion the requirements come from
a type opened during assignment - https://github.com/swiftlang/swift/pull/80081/files.
Resolves: https://github.com/swiftlang/swift/issues/84150
This change adds detection for nested type references in KeyPath
components and applies the appropriate fix to generate meaningful error
messages, following the same pattern already established for method
references.
The fix ensures that invalid KeyPath references fail gracefully in
normal mode and provide helpful diagnostics in diagnostic mode,
improving the developer experience when working with KeyPaths.
Resolves: https://github.com/swiftlang/swift/issues/83197
For a method key path use the locator for the apply itself rather
than the member, ensuring we handle invalid cases where the apply is
the first component, and providing more accurate location info.
Set an upper bound on the number of chained lookups we attempt to
avoid spinning while trying to recursively apply the same dynamic
member lookup to itself.
rdar://157288911
Fix "affected" declaration computation to handle situations when
a generic type happens to be in a closure parameter position.
Resolves: rdar://150068895
It's difficult to trigger this because the code path is only
reached for the standard operators. The issue in question was
in embedded Swift due to an unsupported usage of the ===
operator, but we expect an upcoming standard library change to
actually make us accept that code.
However, the fix should be pretty safe, even without a test case.
Fixes the crash in rdar://156095800.
When importing C++ methods, Swift always assumes that methods named `begin()` and `end()` are unsafe, since these methods commonly return iterator types that are inherently unsafe in Swift.
Some additional logic in Sema tries to diagnose usages of `.begin()` and `.end()` from Swift and suggest safe alternatives. That logic had a null pointer dereference bug.
rdar://153814676 / resolves https://github.com/swiftlang/swift/issues/82361
Diagnostics can outlive the ConstraintSystem itself if we have a
diagnostic transaction for e.g `typeCheckParameterDefault`, make sure
we don't try to use a solver-allocated type as an argument.
Currently the note is going to point to the "callee" but that is
incorrect when the failure is related to an argument of a call.
Detect this situation in `RValueTreatedAsLValueFailure::diagnoseAsNote`
and produce a correct note.
Resolves: rdar://150689994
