We still need to solve a branch with a ReturnStmt to avoid leaving
the contextual result type unbound. This isn't currently legal anyway,
so isn't likely to come up often in practice, but make sure we can
still solve.
We still want to record this fix when falling back to type-checking
as a regular function body to ensure that in cases where there is a
disjunction of multiple result builders we favor the one that actually
supports the body.
To avoid spurious diagnostics about unavailable operations when checking uses
of functions that take result builder closures, lookup of result builder
operations needs to ignore the restrictions of the `MemberImportVisibility`
feature. The result builder transform should simply use the operations that are
found and allow later checks to diagnose the use of inaccessible builder
operations.
Resolves rdar://144100445.
Fixes implementation issue where build block is type-checked as part
of `buildEither(...)`. This is incorrect according to the original
proposal (SE-0289), `buildBlock` should be type-checked independently
and `buildEither` should have no effect on what overload of `buildBlock`
gets selected.
Memory unsafety in the iteration part of the for-in loop (i.e., the part
that works on the iterator) can be covered by the "unsafe" effect on
the for..in loop, before the pattern.
Just because the type of the initializer expression is an opaque return type,
does not mean it is the opaque return type *for the variable being initialized*.
It looks like there is a bit of duplicated logic and layering violations going
on so I only fixed one caller of openOpaqueType(). This addresses the test case
in the issue. For the remaining calls I added FIXMEs to investigate what is
going on.
Fixes https://github.com/swiftlang/swift/issues/73245.
Fixes rdar://127180656.
FunctionRefKind was originally designed to represent
the handling needed for argument labels on function
references, in which the unapplied and compound cases
are effectively the same. However it has since been
adopted in a bunch of other places where the
spelling of the function reference is entirely
orthogonal to the application level.
Split out the application level from the
"is compound" bit. Should be NFC. I've left some
FIXMEs for non-NFC changes that I'll address in a
follow-up.
Remove code that aborts the result builder transform when we encounter
a case that has no statements in it. This can occur when the only
statements were behind a `#if` that evaluataed empty, so it should not
cause an abort.
Previously, the presence of an IfConfigDecl within the case statement
would have prevented us from aborting the traversal here. However, the
removal of IfConfigDecl from the AST turned this previously-accepted
code into a compiler crash.
Fixes rdar://139312426.
Some statements introduce implicit braces and other things,
`walkExplicitReturnStmts` cannot ignore that while trying
to find explicit returns.
Resolves: rdar://139235128
Ensure the implicit `do` statement has a source
range that covers the `for` loop by changing the
source location for the initial binding. This ensures
we correctly detect the code completion child and
avoid skipping it.
Also rename it to `getExplicitReturnStmts` for clarity and have it
take a `SmallVector` out parameter instead as a small optimization and
to discourage use of this new method as an alternative to
`AnyFunctionRef::bodyHasExplicitReturnStmt`.
Use `preCheckTarget` to pre-check the body,
allowing us to replace `PreCheckResultBuilderRequest`
with a request that only checks the brace for
ReturnStmts.
Previously we would skip any expression in a
result builder that didn't contain the completion
token, but that would cause issues if e.g the
result builder was needed to infer the type of a
variable that we're completing on. Instead, only
skip expressions in a result builder if the
completion token is in the same builder and the
expression itself doesn't contain the completion.
rdar://127154780
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
`getLoc` does not necesarrily return the start location of the location (e.g. for `a.b().c()` it returns the location of `c` because that’s the location of the call). But we used the location from `getLoc` as the start location of the synthesized `buildExpression` call. In the added test case, this means that the `buildExpression` call only contained `everlay() {}` and not the code completion token. We thus infered that we could skip it the entire `MyStack {}.pnTabGesture {}.everlay() {}` call for code completion, which isn’t correct.
rdar://120798355
