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.
A default argument generator must not return a @noescape function type.
Returning a @noescape function is nonsense. That means the function escapes.
* Assert that we don't return @noescape function types
* Fix for throwing default arguments
* Add more test cases
* Adapt to mangling changes
Part of:
SR-5441
rdar://36116691
Replace ImplicitlyUnwrappedCoercionResult with the more general
ImplicitlyUnwrappedValue.
Add ImplicitlyUnwrappedDisjunctionChoice as a marker that indicates
that we've already created a disjunction from an
ImplicitlyUnwrappedValue, in order to avoid infinite recursion during
binding.
Also add support to buildDisjunctionForImplicitlyUnwrappedOptional for
functions returning optionals.
NFC.
For casts like 'x as T!' or 'x as! T!', generate a disjunction that
attempts to bind both the optional and non-optional T, preferring the
optional branch of the disjunction.
Note that this should effectively be NFC at the moment because we're
still generating the IUO type for T! rather than a plain optional, so
we first attempt the IUO type (as opposed to an Optional<T>) which
goes through existing logic that handles the IUOs as part of the type
system.
The new rewriting logic will actually do something once we switch over
to generating Optional<T> when T! is uttered.
Add a new OverloadChoiceKind for decls that are either IUO-typed, or
function-typed meaning that the function result type is IUO-typed.
Not currently used, so NFC.
Constructing a keypath expression that references a class member
needs to validate all other members of the class (or a protocol,
but I couldn't reproduce a crash with that case -- added a test
anyway).
Fixes <rdar://problem/36083061>.
This is a corner case but would previously lead to a compiler crash
or miscompile.
Fixes <rdar://problem/21991470>, <https://bugs.swift.org/browse/SR-5022>.
Early on in the development of conditional conformances, we put in a bunch
of assertions for code that uses `conformsToProtocol()` but wasn't handling
conditional conformances. Now, `conformsToProtocol()` handles conditional
conformances by default, and these assertions are tripping up code
that would work.
Remove the assertions and add test cases that used to trip up the
assertions (but now work).
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.
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.
Fix problem related to Swift 3 mode (with assertions),
since Swift 3 mode allows passing arguments with extra parens
to parameters which don't expect them, it should be supported
by "deep equality" types e.g. Optional<T>:
```swift
func foo(_: (() -> Void)?) {}
func bar() -> ((()) -> Void)? { return nil }
foo(bar) // This expression should compile in Swift 3 mode
```
Resolves: rdar://problem/35198459
Consider different overload choices for the same location in evaluation
order, this makes overload resolution more predictable because it's going
to follow expression bottom-up, that prevents situations when some
expressions are considered ambigious because choices taken further up
equate the score, instead each level is given distinct weight
based on evaluation order.
Resolves: rdar://problem/31888810
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.
* If we have an updatable ClosureExpr, then both fromEI.isAutoClosure()
and toEI.isAutoClosure() must be false because the type system ensures
that normal closures and functions do not convert to auto-closures.
* If we have a throwing ClosureExpr, then fromEI.throws() and
toEI.throws() must be true, otherwise an erroneous throwing to
non-throwing closure/function conversions would be possible. From a
different perspective, updating the 'throws' bit would make sense if
overloading on 'throws' wasn't possible.
Except GenericEnvironment.h, because you can't meaningfully use a
GenericEnvironment without its signature. Lots less depends on
GenericSignature.h now. NFC
This allows determining which requirements make a conformance conditional; as
in, which requirements aren't known as part of the type itself.
Additionally, use this to assert that a few builtin protocols aren't
conditionally-conformed-to, something we won't support for now.
