Skip fixing situation where source and destination of assignment are both
nominal types with different optionality until restriction is attempted.
Otherwise fix could be too greedy and diagnose valid code if all of the
types are known in advance.
Resolves: SR-13951
Resolves: rdar://problem/72166791
Detect that direct callee couldn't be resolved e.g. due to an
invalid reference or a missing member and fail instead of
triggering an assert.
Resolves: rdar://problem/71525503
Restore recently removed logic to mark type variable representing
closure parameter used in the body of a closure as potentially
incomplete to delay attempting it until `BindParam` is simplified.
Resolves: rdar://problem/71858936
Unwrap `InOutExpr` from all parens until the outermost paren or a tuple
to correctly diagnose calls like `foo(((&bar)))` or `foo(x: (&bar))`,
and suggest a fix-it with moves `&` outside parens.
Resolves: rdar://problem/71356981
In the single-element case, it is treated as the dictionary key.
func takesDict(_ x: [Int: String]) {}
takesDict([]) // diagnose with fixit to add missing ':'
takesDict([1]) // diagnose with fixit to add missing ': <#value#>'
takesDict([foo.<complete>]) // prioritise Int members in completion results -
// the user just hasn't written the value yet.
The above previously failed with a generic mismatch error in normal type
checking (due to the literal being parsed as an array literal) and code
completion could not pick up the expected type from the context.
Use the FullyQualified<Type> abstraction from the prior commit plus DescriptiveDeclKind to give a bit more information when issuing a missing member type diagnostic during type resolution.
Let's consider conditional requirement failure to mean that parent
conformance requirement wasn't satisfied and nothing more, that helps
to disambiguate certain situations and avoid filtering out conditional
failures.
Resolves: rdar://problem/64844584
If there is a conformance failure related to existential conversion
let's ignore that fact that there could be an implicit value-to-optional
conversion involved, because it's not the main issue in cases like
that.
Resolves: rdar://problem/70814576
"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
