These allow multi-statement `if`/`switch` expression
branches that can produce a value at the end by
saying `then <expr>`. This is gated behind
`-enable-experimental-feature ThenStatements`
pending evolution discussion.
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
Previously we would wait until CSApply, which
would trigger their type-checking in
`coercePatternToType`. This caused a number of
bugs, and hampered solver-based completion, which
does not run CSApply. Instead, form a conjunction
of all the ExprPatterns present, which preserves
some of the previous isolation behavior (though
does not provide complete isolation).
We can then modify `coercePatternToType` to accept
a closure, which allows the solver to take over
rewriting the ExprPatterns it has already solved.
This then sets the stage for the complete removal
of `coercePatternToType`, and doing all pattern
type-checking in the solver.
Rather than eagerly binding them to holes if the
sequence element type ends up being Any, let's
record the CollectionElementContextualMismatch fix,
and then if the patterns end up becoming holes,
skip penalizing them if we know the fix was
recorded. This avoids prematurely turning type
variables for ExprPatterns into holes, which
should be able to get better bindings from the
expression provided. Also this means we'll apply
the logic to non-Any sequence types, which
previously we would give a confusing diagnostic
to.
Instead of assuming that `if let <expr>` is meant
to be `if case <expr> = ...`, turn it into
`if let _ = <expr>`, which is consistent with
the fix-it we suggest.
This currently doesn't have much of an effect on
the diagnostics we produce, but will be important
once we start doing bidirectional inference for
ExprPatterns, as it avoids unhelpful diagnostics.
Emulate previous `for-in` type-checking behavior where sequence
was type-checked separately from `.next()` call which, in turn,
was injected only during SIL generation.
Current approach to generate an implicit variable for `$generator`
and use it as a base to `.next()` call didn't account for the fact
that it allows the solver to rank result of `<sequence>.makeIterator()`
together with result of `next()`. This is logically incorrect because
`<sequence>.makeIterator()` represents initializer of `$generator`
which is separate from `$generator.next()` expression albeit type-checked
together.
Resolves: https://github.com/apple/swift/issues/59522
Instead of asking SILGen to build calls to `makeIterator` and
`$generator.next()`, let's synthesize and type-check them
together with the rest of for-in preamble. This greatly simplifies
interaction between Sema and SILGen for for-in statements.
When recovering from a parser error in an expression, we resumed parsing at a '{'. I assume this was because we wanted to continue inside e.g. an if-body if parsing the condition failed, but it's actually causing more issue because when parsing e.g.
```swift
expr + has - error +
functionTakesClosure {
}
```
we continue parsing at the `{` of the trailing closure, which is a completely garbage location to continue parsing.
The motivating example for this change was (in a result builder)
```swift
Text("\(island.#^COMPLETE^#)")
takeTrailingClosure {}
```
Here `Text(…)` has an error (because it contains a code completion token) and thus we skip `takeTrailingClosure`, effectively parsing
```swift
Text(….) {}
```
which the type checker wasn’t very happy with and thus refused to provide code completion. With this change, we completely drop `takeTrailingClosure {}`. The type checker is a lot happier with that.
Add a test for an extremely confusing behavior of switches for
ExpressibleByNilLiteral-conforming types. From the looks of the expression
tree, one would hope that `case nil` would match such types. Instead, the
subject value is up-converted to an optional and compared to `nil` directly
with ~=.
There were some tests that relied on the top-level code not being an
asynchronous context to emit certain error messages. Now that it is,
those tests weren't emitting the expected error message.
In other cases, the issue was that they were trying to initialize a
global variable and weren't really using top-level code as top-level
code, so adding `-parse-as-library` was sufficient for the testing
purposes.
To fix the objc_async test, parsing as a library was nearly sufficient.
Unfortunately, the little `if #available` trick that I was using stopped
working since it relied on being in top-level code. So that we emit the
unavailableFromAsync error message, I had to set the availability on
everything correctly because we can't just disable availability
checking.
This is an anti-pattern since the resulting value will never compare equal to `nil`, and the entire switch-case is dead. This appears to be a misfeature as the subject value is simply type-checked against an optional which produces an injection which matches the global ~= for Optionals.
Effectively, `case nil:` becomes `case $match ~= nil`.
rdar://89742267
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
The following regression test added for this feature is not passing:
Swift(linux-x86_64) :: decl/protocol/protocols_with_self_or_assoc_reqs_executable.swift
with a compiler crash happening during SILFunctionTransform "Devirtualizer".
Reverting to unblock CI.
This reverts commit f96057e260, reversing
changes made to 3fc18f3603.
While 'defer' is implemented as a local function, it doesn't
behave as one. In particular, since SILGen runs it after
destroying all local bindings that appear after the 'defer'
definition, the body of a 'defer' cannot forward reference
captured bindings the way that local functions can.
Note that I had to remove a SILGen test case for an older,
related issue. The new diagnostic in Sema catches these cases
earlier.
Fixes rdar://problem/75088379.
