In C++, `std::nullopt` is implicitly convertible to `std::optional<T>`. Swift doesn't support implicit type conversions between arbitrary types. Instead, the developer is expected to use `nil` literal, which is implicitly converted to `std::optional<T>`. This works via `CxxOptional`'s conformance to `ExpressibleByNilLiteral`.
This improves the diagnostic produced by Swift for the attempted usage of `std::nullopt` in places where the type conversion expected by the developer doesn't happen. A note will now be emitted:
```
use the 'nil' literal instead
```
rdar://162203520
Key paths rooted at a protocol metatype could slip through the normal metatype checks and reach SILGen when they referenced a static property like \.foo. That left the compiler in the wrong state and could crash instead of producing a targeted error.
Teach constraint fixing to reject static member references through protocol metatype roots, add a dedicated diagnostic for that case, and consistently treat metatype bases as AnyMetatypeType during type checking and SILGen.
Adds a new DynamicMemberLookupSubscriptRequest type for evaluating and
caching the validity of a `SubscriptDecl`'s usage to fulfill a
`@dynamicMemberLookup` requirement for a specific usage.
`SubscriptDecl` exposes eligibility for `@dynamicMemberLookup`
requirements directly, so the `TypeChecker` interface for these members
can be replaced.
Teach the missing argument diagnostic about pattern matches, there
was no diagnostic for this situation at all which results in
"failed to produce a diagnostic" fallback when this happens.
Resolves: rdar://167455709
Teach `MissingArgumentsFailure` that a "source" of the assignment could
be a closure that has some of the expected arguments missing. For function
values in the same situation, produce a generic conversion mismatch
diagnostic.
Resolves: https://github.com/swiftlang/swift/issues/87818
Resolves: rdar://172316156
This was previously used to control whether a CxxRecordSemantics or
CxxRecordAsSwiftType request would trigger diagnostics when determining
a type is a foreign reference type. That interface led to obscure
control flow and was removed recently. This patch removes the vestigial
pointer field those requests used.
(Actually, that pointer was *never* used by CxxRecordAsSwiftType
requests; its call sites just happened to pick it up because it shares
the same input descriptor type as CxxRecordSemantics).
rdar://170858418
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.
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
Egor Zhdan
Madushan Gamage
Slava Pestov
Aidan Hall
Pavel Yaskevich
Pavel Yaskevich
Doug Gregor
Hamish Knight
John Hui
Artem Chikin
Aviva Ruben
Becca Royal-Gordon
Anthony Latsis
Tim Kientzle
naveen-seth
Allan Shortlidge
Meghana Gupta
Konrad `ktoso` Malawski
Meghana Gupta