Allow certain bindings and conversions involving non-escaping
function types to succeed in "diagnostic" mode to gather fixes
and diagnose such problems better, expecially related to
conversions to 'Any' and generic parameters.
Resolves: rdar://problem/38648760
Currently we always use 'FunctionResult' as a path element when matching
function result types, but closure result type is allowed to be implicitly
converted to Void, which means we need to be careful when to use
'FunctionResult' and 'ClosureResult'.
Resolves: rdar://problem/37790062
* Implement the recently accepted SE-0195 proposal, which introduces "Dynamic
Member Lookup" Types. This is a dusted off and updated version of PR13361,
which switches from DynamicMemberLookupProtocol to @dynamicMemberLookup as
was requested by the final review decision. This also rebases it,
updates it for other changes in the compiler, fixes a bunch of bugs, and adds support for keypaths.
Thank you to @rudx and @DougGregor in particular for the helpful review comments and test cases!
Allow functions with type `(()) -> T` to be passed in places where we
expect `() -> T`, but only for -swift-version 4 (for -swift-version 3
this already works due to other horrible things in CSSimplify.cpp).
We need to look at how we can help migrate these cases to
-swift-version 5, but in the meantime, but that is something we can
consider separately.
We inadvertantly allowed a function conversion for Swift 4 that we did
not intend to allow.
This commit adds an extremely narrow fix to continue to allow this for
-swift-verson 4 only.
Fixes rdar://problem/36875195 / https://bugs.swift.org/browse/SR-6837
Increase solution score when performing function conversions where only
one side has `@autoclosure`. That is going to help pick the best overload
when only difference lays in presence of such attribute.
e.g.
```swift
func foo(_: @autoclosure () -> Int) {}
func foo(_: () -> Int) {}
```
If the argument is itself `@autoclosure` it's preferable to use overload
with `@autoclosure` attribute, otherwise `() -> Int` should be used.
Resolves: rdar://problem/37160679
Also remove the decl from the known decls and remove a
bunch of code referencing that decl as well as a bunch of other
random things including deserialization support.
This includes removing some specialized diagnostics code that
matched the identifier ImplicitlyUnwrappedOptional, and tweaking
diagnostics for various modes and various issues.
Fixes most of rdar://problem/37121121, among other things.
This partially reverts commit 8685ee01a1.
The tests are still in place, but the code change is no longer necessary
now that IUOs are removed from the type system.
Fixes: rdar://problem/37013789
Allow passing Optional<T> as inout where
ImplicitlyUnwrappedOptional<T> is expected, and vice-versa.
Swift 4.1 added a warning that overloading inouts by kind of optional
was deprecated and would be removed, but we didn't actually allow
people to remove an overload and pass arguments of the other kind of
optional to the remaining function.
Fixes rdar://problem/36913150
Class constraints (spelled T: AnyObject) on generic types were not
getting checked on generic arguments. This appears to be a regression
introduced in Swift 4.0 with the removal of AnyObject, leading to a
fairly significant soundness hole that could produce crashers later
on.
Fixes SR-6841 / rdar://problem/36884025.
When binding an optional value, or function that returns an optional
value, if that value was produced from a decl that was declared an
IUO, create a disjunction.
After solving, make use of the disjunction choices in rewriting
expressions to force optionals where needed.
This is disabled for now, as it results in a source compatibility
issue without associated changes that actually start generating
Optional<T> in place of ImplicitlyUnwrappedOptional<T>. It's
complicated, but basically having two '??' (one returning T, one
returning T?) and creating a disjunction where the first (favored)
choice is ImplicitlyUnwrappedOptional<T> and second is T results in
our selecting the wrong '??' in some cases.
Use this in places where we have a decl that is marked with the
ImplicitlyUnwrappedOptionalAttr so that we can distinguish in the
solver which decls need to be potentially unwrapped in order to type
check successfully.
It's probably harmless to record the ones for failures which later cause
us to back out in the solver, but it means we cannot easily set
breakpoints in places like recordFix and stop only in the places where
the fixes actually cause the solution to make progress.
These purportedly mark that we should stop attempting fixes for a given
constraint, but in fact the only code creating these is clearly
unreachable so these serve no purpose.
Fix collection subtyping relation in function argument position
by emiting special re-abstraction thunk with collection upcast.
Resolves: rdar://problem/35702810
We now store an entire OverloadChoice in the unviable candidates
list (which is used for error recovery), just like we store them
for viable candidates.
The additional information isn't used, so NFC.
conformsToProtocol() is the main way in which we check whether a given type
conforms to a given protocol. Extend it to check conditional requirements by
default, so that an unmodified caller will get the "does not conform" result
(with diagnostics when a location is present) rather than simply ignoring
the conditional requirements.
Some callers take responsibility for conditional requirements, e.g., to
push them into the constraint system. Allow those callers to opt out of
this checking, and do so wherever appropriate.
Fixes rdar://problem/35518088, where we were ignoring the conditional
requirements needed to verify that Equatable synthesis could be performed.
Using this constraint locator element, we can check when a failed
constraint is due to an unsatisfied conditional requirement of a
protocol conformance. Unfortunately, it's hard to turn this into
an actionable diagnostic right now.
Rather than wantonly dropping the conditional requirements when checking
for type erasure, add them in the same way we do for (e.g.) conformance
checking for generics. Fixes rdar://problem/35480860.
We added this hack to work around the use of context types within normal
protocol conformances, which created tautological constraint systems.
With the switch to interface types in normal protocol conformances, this
hack is no longer necessary.
When testing KeyPathApplication constraints, we would keep going after rejecting a concrete KeyPath application by trying PartialKeyPath and AnyKeyPath, even though that's not what we want, since any key path application expression can type check with an AnyKeyPath. We would then miscompile by building the AST such that we applied the mismatched key path expression directly to the base. We also didn't handle expressions where the base was a subtype of the key path's base type correctly—the conversion means the base can't be written through in this situation, and we hardcoded the concrete-to-existential case instead of handling general conversions. Fix these problems, and add an AST verifier for KeyPathApplicationExprs to help catch problems in the future. Fixes SR-6300 | rdar://problem/35368903.
Remove function-to-function type match score increase, which should only
happen contextually in presence of other restrictions, this used to fix
the case related to matching of arrays of functions with and w/e `throws`
as function parameters which used to be ambigious, and now handled by
collection-upcast conversion score.
Resolves: rdar://problem/35142121
