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
If a type variable representing "function type" is a hole
or it could be bound to some concrete type with a help of
a fix, let's propagate holes to the "input" type. Doing so
provides more information to upcoming argument and result matching.
A TopLevelCodeDecl is a local context and any declarations inside
of one must be treated as captures. Furthermore, all the
TopLevelCodeDecl children of a source file are peers, and can
see each other's bindings, so don't perform an exact match on the
DeclContext.
Part of <rdar://problem/23051362> / <https://bugs.swift.org/browse/SR-3528>.
* 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
Since `binding` has all of the required information now it's possible
to use its `locator` as a source of type variable assignment
(`Bind` constraint) in `TypeVariableBinding::attempt` which helps
to improve diagnostics.
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.
* [Sema][Diagnostics] Add fixit for warning when inferring an undesirable type
* [Sema][Diagnostics] Generalize undesirable type warning to include arrays of empty tuples
https://bugs.swift.org/browse/SR-11511
All of the argument diagnostics have been ported to the new diagnostic
framework, so now is the time to remove `ArgumentMatcher` and the only
place where it was used - `diagnoseSingleCandidateFailures`.
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.
Argument-to-Parameter mismatch handles conformance failures
related to arguments, so the logic in `MissingConformanceFailure`
which wasn't entirely correct is now completely obsolete.
Resolves: rdar://problem/56234611
