Impose the same limit we impose on other
forms of control flow statements (e.g `break`,
`continue`, `return`), where it cannot transfer
control out of the expression. This fixes a crash
where we'd fail to find a fallthrough nested in an
`if` expression. It is technically source breaking,
as we would have allowed the case where the `if`
expression is a directly nested result of an outer
`switch` expression, but I would be very surprised
if anyone is relying on that.
rdar://133845101
Allow `fallthrough` to appear as the last statement
in the case of a `switch` expression. We already
allowed it in other positions, this was just an
oversight.
rdar://127670432
Make it clear the issue is the transfer of
control flow out of the `if`/`switch` expression.
Technically things like `break` and `continue` are
allowed, as long as they are not jumping out of
the expression.
Doing it in the post-walk meant we ended up
walking the children twice, which lead to duplicate
diagnostics and incorrect inference of the
level of application for function references. Move
it to the pre-walk, ensuring that we resolve any
operator references before folding.
Make sure `CouldNotInferPlaceholderType` can
produce a diagnostic for a `PlaceholderType`
locator element, and avoid emitting an extra
diagnostic for a placeholder type in an invalid
position.
The issue is that the shorthand if let syntax injects an implicit
expression: https://github.com/apple/swift/pull/40694/ in ParseStmt and
that the 'diagnoseUnhandledAsyncSite' explicitly avoids reporting errors
in implicit expressions.
This change is that we don't mark the implicit declref code emitted by
the `if let prop` as implicit anymore, and this way the reporting works
out as expected.
Added some tests covering this as well as properly erroring out for the
nonexistent syntax of shortand + awaiting which doesn't exist, and we
properly error on it.
Resolves rdar://126169564
Unfortunately we've encountered another source
breaking case here:
```
class C {
func method() {}
func foo() {
Task { [weak self] in
Task {
method()
}
}
}
}
```
In 5.10 we'd only do the unqualified lookup for
`self` when directly in a `weak self` closure,
but with the implicit self rework, we'd start
using the `weak self` here, leading to a
type-checker error.
At this point, adding more edge cases to the
existing logic is going to make things much more
complicated. Instead, reinstate the 5.10 implicit
self lookup behavior and diagnostic logic,
switching over to the new logic only under Swift 6
mode.
rdar://129475277
In 5.10 we warned on this:
```swift
func bar(@_implicitSelfCapture _ fn: @escaping () -> Void) {}
class C {
func foo() {
bar { [weak self] in
foo()
}
}
}
```
But with the implicit self rework, this accidentally
became an error. Fix it to ensure we continue to
warn until Swift 6 mode.
rdar://128941797
When using shorthand syntax for optional binding,
if the variable we are binding is accessed asynchronously,
provide an insertion fixIt of the form: ' = await (identifier)'.
Previously, we would suggest only adding the 'await'
which resulted in an error since the identifier is required.
Functions can in fact conform to some protocols, notably,
marker protocols. Dynamically they have no influence on whether the cast
will succeed or not, as there is no way to tell if a type conforms to
such a protocol at runtime. But we should check them statically because
they otherwise can be cast to Any eventually.
Remove keypath subtype asserts; always use cached root type
Add tests for keypaths converted to funcs with inout param
Add unit test for overload selection
This removes the distinction between argument completions and postfix expr paren completions, which was meaningless since solver-based completion.
It then determines whether to suggest the entire function call pattern (with all argument labels) or only a single argument based on whether there are any existing arguments in the call.
For this to work properly, we need to improve parser recovery a little bit so that it parsers arguments after the code completion token properly.
This should make call pattern heuristics obsolete.
rdar://84809503
In asserts builds this hits an assert that the
feature isn't enabled, and in no-asserts builds
this incorrectly allows `do` expressions to be
used with the feature disabled. Note this only
affects their use when nested in an `if`/`switch`
that is used in a binding, we correctly handled
the other cases.
rdar://121193678
