"Function builders" are being renamed to "result builders". Add the
corresponding `@resultBuilder` attribute, with `@_functionBuilder` as
an alias for it, Update test cases to use @resultBuilder.
I created a second copy of each test where the output changes
after disabling parser lookup. The primary copy now explicitly
calls the frontend with -disable-parser-lookup and expects the
new diagnostics; the *_parser_lookup.swift version calls the
frontend with -enable-parser-lookup and has the old expectations.
This allows us to turn parser lookup on and off by default
without disturbing tests. Once parser lookup is completely
removed we can remove the *_parser_lookup.swift variants.
Before considering `nil` to be used without a context, let's
check whether parent expression (semantic significance of
which is not important) has a contextual type associated with it,
otherwise it's possible to misdiagnose cases like:
```swift
func test() -> Int? {
return (nil)
}
```
If there are multiple overloads and all of them require explicit
base type for a member reference, let's diagnose it as a single
error since the problem is the same across the overload choices:
```swift
func foo<T>(_: T, defaultT: T? = nil) {}
func foo<U>(_: U, defaultU: U? = nil) {}
foo(.bar)
```
In this example there is not enough contextual information to
determine base type of `.bar` reference and hence both `foo`
overloads are a considered valid solutions until explicitly set
base type disambiguates them.
Resolves: rdar://problem/66891544
The lack of these functions in a function builder is diagnosed in
different places in the type checker. Extend these diagnostics to
provide stubs in the function builder.
Thanks to Suyash for the suggestion!
When a use of a function builder involves a statement kind that the
function builder doesn't support (e.g., if-else), add a note to the
diagnostic that specifies what methods need to be added to the
function builder to support that statement, including Fix-Its with
stub implementations.
Currently its impact is set to be less than that of a conversion fix,
which is incorrect. Let's adjust that and increase it even farther for
cases where base is `Any` or `AnyObject`. We couldn't do it for `Any`
before because it was used to represent type holes, but it's no longer
the case.
Resolves: rdar://problem/68155466
Allow an 'async' function to overload a non-'async' one, e.g.,
func performOperation(_: String) throws -> String { ... }
func performOperation(_: String) async throws -> String { ... }
Extend the scoring system in the type checker to penalize cases where
code in an asynchronous context (e.g., an `async` function or closure)
references an asychronous declaration or vice-versa, so that
asynchronous code prefers the 'async' functions and synchronous code
prefers the non-'async' functions. This allows the above overloading
to be a legitimate approach to introducing asynchronous functionality
to existing (blocking) APIs and letting code migrate over.
If base type of a unresolved member reference couldn't be determined
(represented as a hole type), before recording a fix about lack of
contextual information, let's make sure that hole originated in either
base or result type of this reference, otherwise the problem is
contextual e.g. generic parameter, which supposed to act as contextual
type for a reference, couldn't be inferred.
If the right-hand side (destination) of value-to-pointer conversion
is incorrect e.g. base type of member is a hole, let's record
a generic "invalid conversion" failure.
Resolves: rdar://problem/68254165
Generally, casting consistency demands that we be able
to extract anything from an existential that can be put
into that existential. (Which is why the casting spec
requires that casting permit arbitrary injection and
projection of optionals.)
This particular diagnostic prevented optionals from being
projected back out of existentials:
let i: Int?
let a: Any = i // Inject Int? into Any
// Error prevents projecting Int? back out of Any
a as? Int?
This also broke certain uses of Mirror (weak variables get reflected as
optionals stored in Any existentials).
Make the lookup of the various `build` functions for function builders
normal, qualified name lookup. This allows (e.g.) the implementation
of many of the 'build' functions to come from a protocol extension,
making function builders more composable. Thank you to @anreitersimon
on the Swift forums for the example!
In the included test case, conformance checking of Wrapper : B would
pick up typealias Foo as a witness for the associated type B.Foo.
However, this typealias Foo is defined in a constrained extension where
T : A, and the underlying type references the associated type A.Foo
on T.
The resulting substitution is invalid when the conformance Wrapper : B
is used in a context where T does not conform to A.
Instead, we should ignore this typealias entirely, since it appears
in an unusable constrained extension.
Fixes <rdar://problem/60219705>, <https://bugs.swift.org/browse/SR-12327>,
<https://bugs.swift.org/browse/SR-12663>.
