Short-circuit calls where all arguments are invalid, otherwise the
solver would end up producing a solution for every overload which
it cannot disambiguate which quickly turns into "too complex" situation.
When a CallExpr's callee is implicit (e.g. `callAsFunction`),
`fn->getEndLoc()` collapses to the call site's location, so the
bare-trailing-closure path could compute `lastLoc` at or past the
closure's start. The resulting `fixItReplaceChars(lastLoc,
closureRange.Start, ...)` produced a degenerate SourceRange that crashed
the Swift-syntax-aware diagnostic renderer when constructing
`Range<AbsolutePosition>`. Detect that case and fall back to a plain
insertion at the closure's start.
fixes rdar://170779809
This is a partial revert of https://github.com/swiftlang/swift/pull/87360
The change attempted to infer a concrete thrown error type onto
the closure but that leads to incorrect solutions when closure is
passed as an argument to an overloaded declaration because the
solver doesn't check whether calls in the body do throw the
expected type even with `FullTypedThrows` feature enabled
and so the safest option is still to assume un-typed `throws`
unless typed throws comes from a concrete contextual type.
Resolves: rdar://173132715
Use closure for defer body
Revert to main
Rework implementation to keep FuncDecl
Add AST briding
Add test with async let
Add main actor tests
Add additional tests
It looks like originally, we would only infer bindings from a
KeyPath type, which has invariant generic arguments. However,
nowadays we can infer a keypath root type from a function
type as well, because we allow keypath to function conversions.
So, if we inferred the key path root type through a function type,
then in fact we cannot introduce it as an exact binding, and
we must preserve variance.
This fixes a test failure that appears with a subsequent change
I'm making.
If we encounter a variable declared after its use within a closure,
we can fallback to using an outer result if present. This matches the
behavior outside of a closure and generally seems more consistent with
the behavior we have if we also find an inner result.
rdar://163656720
Previously we would allow these in Sema and diagnose them in SILGen,
but allowing them in Sema is unsound because it means the constraint
system ends up kicking interface type requests for declarations that
should be type-checked as part of the closure itself. Adjust the
name lookup logic to look through parent closures when detecting
invalid forward references.
For now we don't fallback to an outer result on encountering a
use-before-declaration to preserve the current behavior. I'm planning
on changing that in the next commit though.
rdar://74430478
`isThrowing` returns `true` for a function type that is `throws(Never)`
even though it's wrong, let's work around that until the underlying issue
is fixed.
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.
Modify relevant portions of the type-checker and parser to allow, when the 'LiteralExpressions' experimental feature is enabled, for arbitrary integer-typed expressions in enum raw value specifiers. These expressions will be type-checked and constant-folded into an integer literal expression, keeping the current interface of 'EnumElementDecl' consistent for clients.
Previously, 'EnumRawValuesRequest' had two different "modes" which were discerned based on typechecking stage (structural | interface), where the former had the request compute all raw values, both user-specified literal expressions and computing increment-derived values as well; the latter would also type-check the user-specified expressions and compute their types.
- With the need to have enum case raw values support arbitrary integer expressions, the request ('EnumRawValuesRequest') has been refactored and simplified to *always* both compute all case raw values and perform type-checking of user-specified raw value expressions. This is done in order to allow the AST-based constant-folding infrastructure ('ConstantFoldExpression' request) to run on the expressions. Constant folding is invoked during the evaluation of 'EnumRawValuesRequest' on all user-specified raw value expressions, in order to be able to compute subsequent increment values and ensure the expressions are foldable. If they are not, i.e. if constant folding fails, a relevant diagnostic will be emitted.
- 'EnumElementDecl' continues to store the raw value expression, which is no longer a 'LiteralExpr' but rather an 'Expr'; however, the getter ('getRawValueExpr') continues to return a 'LiteralExpr' by invoking the constant-folding request on the stored value, which is guaranteed to return a cached result from a prior invocation in 'EnumRawValuesRequest', assuming it succeeded.
- Furthermore, the 'structural' request kind was previously not cached, whereas now because the request must always do the complete type-checking work, it is always cached.
Resolves rdar://168005520
This fixes an ambiguity introduced by the stdlib change in
0f99458900.
Since (borrowing T) -> () and (T) -> () both convert to
each other, we could end up with ambiguous solutions where
neither one was better than the other. Generalize the
existing trick we use for labeled vs unlabeled tuples to
also strip off ownership specifiers and @convention(...)
from function types. This fixes the regression, as well
an existing FIXME in a test I added a while ago where
the same problem arises with @convention(block).
A key path component that resolved to an `ErrorExpr` would be diagnosed twice: once when the `ErrorExpr` was created, then again when it was processed. Fix this redundant diagnostic.
The legacy parser has a special case for code like `fn(:)` which corrects it to `fn(_:)`, but the new `::` token was interfering with cases where there were two adjacent colons (e.g. `fn(::)`). Correct this issue.
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
This never worked correctly and would crash in SILGen, ban the use
of placeholder types. While here, ensure we replace any ErrorTypes
with holes when solving the closure in the constraint system.
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
Diagnose the availability of the specific accessors that are referenced
implicitly via a key path reference. This causes setter availability to be
diagnosed when passing a key path to a function that takes a `WritableKeyPath`.
Resolves rdar://157232221.
This is a diagnostic that is only really emitted as a fallback when
the constraint system isn't able to better diagnose the expression.
It's not particulary helpful for the user, and can be often be
misleading since the underlying issue might not actually be an
ambiguity, and the user may well already have a type annotation. Let's
instead just emit the fallback diagnostic that we emit in all other
cases, asking the user to file a bug.
In implicit contexts that are universally unavailable, allow writable key paths
to be formed to properties with setters that are also marked as universally
unavailable. This fixes a regression from the previous commit where the code
synthesized for `@Observable` properties in universally unavailable classes was
rejected by the availability checker.
Previously, only conditional unavailability was considered, but setters that
are always unavailable must also make a keypath read-only.
Resolves rdar://155832511.
Pavel Yaskevich
Ben Cohen
Freddy Kellison-Linn
Slava Pestov
Hamish Knight
Pavel Yaskevich
Rintaro Ishizaki
Cal Stephens
Artem Chikin
Jamie
AnirudhMathur12
bashir
Anthony Latsis
Becca Royal-Gordon
Henrik G. Olsson
Allan Shortlidge
Felipe Mussi Ferreira Peixoto
Mykola Pokhylets