Instead of failing constraint generation upon encountering
an invalid declaration, let's turn that declaration into a
potential hole and keep going. Doing so enables the solver
to reach a solution and diagnose any other issue with
expression.
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.
We'll need this to get the right 'selfDC' when name lookup
finds a 'self' declaration in a capture list, eg
class C {
func bar() {}
func foo() {
_ = { [self] in bar() }
}
}
If reference collection discovered at least `ErrorExpr` in the body
of a closure, let's fail constraint generation only if it's a
single-statement closure, decision about multi-statement closures
should be delayed until body is opened.
This helps code completion because `ErrorExpr` could belong to
a statement unrelated to a completion, so it wouldn't affect
its correctness in any way.
Fix a regression introduced by moving the type checking of closure
captures into the constraint system. The pattern-type optimization for
initializations was causing inference of a double-optional where there
shouldn't be one, manifesting in a failure involving implicitly
unwrapped optionals and `weak self` captures.
Fixes rdar://problem/67351438.
Rather than type-checking captures as separate declarations during
pre-check, generate constraints and apply solutions to captures in
the same manner as other pattern bindings within a constraint
system.
Fixes SR-3186 / rdar://problem/64647232.
This approach, suggested by Xiaodi Wu, provides better source
compatibility for existing Swift code, by breaking ties in favor of the
existing Swift semantics. Each time the backward-scan rule is needed
(and differs from the forward-scan result), we will produce a warning
+ Fix-It to prepare for Swift 6 where the backward rule can be
removed.
Whenever we form a call that relies on the deprecated "backward" scan,
produce a warning to note the deprecation along with a Fix-It to label
the parameter appropriately (and suppress the warning). For example:
warning: backward matching of the unlabeled trailing closure is
deprecated; label the argument with 'g' to suppress this warning
trailingClosureEitherDirection { $0 * $1 }
^
(g: )
To better preserve source compatibility, teach the constraint
solver to try both the new forward scanning rule as well as the
backward scanning rule when matching a single, unlabeled trailing
closure. In the extreme case, where the unlabeled trailing closure
matches different parameters with the different rules, and yet both
produce a potential match, introduce a disjunction to explore both
possibilities.
Prefer solutions that involve forward scans to those that involve
backward scans, so we only use the backward scan as a fallback.
The change to the forward-scanning rule regressed some diagnostics,
because we no longer generated the special "trailing closure mismatch"
diagnostic. Reinstate the special-case "trailing closure mismatch"
diagnostic, but this time do so as part of the normal argument
mismatch diagnostics so it is based on type information.
While here, clean up the handling of missing-argument diagnostics to
deal with (multiple) trailing closures properly, so that we can (e.g)
suggest adding a new labeled trailing closure at the end, rather than
producing nonsensical Fix-Its.
And, note that SR-12291 is broken (again) by the forward-scan matching
rules.
Detect situation when it's impossible to determine types for
closure parameters used in the body from the context. E.g.
when a call closure is associated with refers to a missing
member.
```swift
struct S {
}
S.foo { a, b in } // `S` doesn't have static member `foo`
let _ = { v in } // not enough context to infer type of `v`
_ = .foo { v in } // base type for `.foo` couldn't be determined
```
Resolves: [SR-12815](https://bugs.swift.org/browse/SR-12815)
Resolves: rdar://problem/63230293
Since `simplifyRestrictedConstraintImpl` has both parent types and
does nested type matching it's a good place to diagnose top-level
contextual problems like mismatches in underlying types of optionals.
Since opening closure body is now delayed until contextual type becomes
available it's possible to infer anonymous parameters as being variadic
based on context and propagate that information down to the closure body.
Resolves: rdar://problem/41416758
* WIP implementation
* Cleanup implementation
* Install backedge rather than storing array reference
* Add diagnostics
* Add missing parameter to ResultFinderForTypeContext constructor
* Fix tests for correct fix-it language
* Change to solution without backedge, change lookup behavior
* Improve diagnostics for weak captures and captures under different names
* Remove ghosts of implementations past
* Address review comments
* Reorder member variable initialization
* Fix typos
* Exclude value types from explicit self requirements
* Add tests
* Add implementation for AST lookup
* Add tests
* Begin addressing review comments
* Re-enable AST scope lookup
* Add fixme
* Pull fix-its into a separate function
* Remove capturedSelfContext tracking from type property initializers
* Add const specifiers to arguments
* Address review comments
* Fix string literals
* Refactor implicit self diagnostics
* Add comment
* Remove trailing whitespace
* Add tests for capture list across multiple lines
* Add additional test
* Fix typo
* Remove use of ?: to fix linux build
* Remove second use of ?:
* Rework logic for finding nested self contexts
If return type is a function, it's possible to return a closure
which can have some of its arguments unused in the body e.g.
`let _: () -> ((Int) -> Void) = { return { } }`
In this case resulting closure has to use its only parameter or
explictly ignore it by declaring `_ in`.
Initially this problem was only detected and diagnosed for calls.
So let's extend it to function conversions as well e.g.:
```swift
func foo<T>(_: [T]) {}
func bar<T>(_ f: (T...) -> ()) {}
bar { foo($0) }
```
In the past, this error was applied inconsistently, so diagnosing it
correctly is now a source-breaking change. Instead, diagnose it correctly,
but as a warning.
automatically.
This commit also renames `ConstraintSystem::recordHole/isHole` to
`recordPotentialHole` and `isPotentialHole` to make it clear that
we don't know for sure whether a type variable is a hole until it's
bound to unresolved.
This helps us to better diagnose failures related to generic
requirements like `T == [Int]` as well as protocol compositions,
which require deep equality check.
Instead, check them and their error handling right away.
In addition to fixing the crash in the radar, this also causes
us to emit unused variable warnings in functions containing
local functions.
Eventually, TC.definedFunctions should go away altogether.
Fixes <rdar://problem/53956342>.
If a syntax sugared type like Array had an unresolved type, it used to print as `[_]` in diagnostics, which could be confusing.
Instead, desugar these unresolved types before printing, so Array, for example, prints as `Array<_>`.
Currently this only applies to Array, Dictionary, and Optional.
This improves the diagnostic for trailing closures in statement conditions to catch cases where one or more trailing closures are used in a chain composed of multiple calls
Enhance call-argument matching to reject trailing closures that match up
with parameters that cannot accept closures at all.
Fixes rdar://problem/50362170.
Let's keep track of type mismatch between type deduced
for the body of the closure vs. what is requested
contextually, it makes it much easier to diagnose
problems like:
```swift
func foo(_: () -> Int) {}
foo { "hello" }
```
Because we can pin-point problematic area of the source
when the rest of the system is consistent.
Resolves: rdar://problem/40537960
We previously allowed these closures to default to (), but be inferred
as other types as well, which means that we will find some expressions
to be ambiguous because we end up finding multiple viable solutions
where there is really only one reasonable solution.
Fixes: rdar://problem/42337247
