And make an attempt to use the constraint system's contextualType to bind type information; this makes things better but doesn't seem to be a complete solution for contextually typing key paths.
It's particularly likely someone will try to type `\(foo)`, which looks like a string interpolation segment, outside of a string literal, so give that case a special diagnostic. Fixes rdar://problem/32315365.
We need to strip inout/lvalue before casting the second parameter's type
to FunctionType.
There were also some verification issues and the fact that we weren't
allowing already-escaping closures to be passed to it (which is not
useful, but shouldn't result in an error and really awful
diagnostic). We can potentially look at diagnosing this with a warning
at some point in the future.
Fixes rdar://problem/32239354.
This is a bit more robust and user-friendly than hoping more brittle recovery in SILGen or IRGen for unsupported components kicks in. rdar://problem/32200714
When casting from an object type to a bridged Swift value type, classifyDynamicCast would use the cast classification for the target type's bridged object type, which would be trivially WillSucceed for thinks like NSNumber-to-Int or NSError-to-SomeError, even though the bridging itself could fail. Fixing this fixes SR-2920|rdar://problem/31404281.
The fix committed in 15fb957f09 still
allows for the possibility that we can bind one type as part of
processing the Equal constraint and then later come along and attempt to
bind the LValue version of that type as part of processing another
constraint.
I don't have a test case for this as it was discovered by thought
process, not testing, and constructing a test case isn't really feasible
because it relies on a lot of specifics about the order in which things
happen to be processed the constraint solver.
We had an inconsistency in the handling of ConstraintKind::Equal in that
we would take
$T1 Equal $T2
where $T2 was previously bound to a type, and bind the RValue type of
$T2's type to $T1. That does not allow for us to later attempt to bind
the LValue type of that type to $T1 (as might happen in simplifying an
OptionalObject constraint).
Instead, if $T1 can be bound to an LValue and $T2 is not an LValue,
we'll defer simplifying the Equal constraint until after $T1 is bound
through some other type variable binding or constraint simplification.
Fixes rdar://problem/31724272.
There were various problems with layout constraints either
being ignored or handled incorrectly. Now that I've exercised
this support with an upcoming patch, there are some fixes
here.
Also, introduce a new ExistentialLayout::getLayoutConstriant()
which returns a value for existentials which are class-constrained
but don't have a superclass or any class-constrained protocols;
an example would be AnyObject, or AnyObject & P for some
non-class protocol P.
NFC for now, since these layout-constrained existentials cannot
be constructed yet.
Now that mayHaveSuperclass() is back to its old meaning, we can't
piggy-back off of it anymore and must add a new bit of logic
for class-constrained existential to superclass conversions.
Also re-organize the code a bit.
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
In particular, it doesn't "toll-free bridge" to the Error existential on non-ObjC-interop platforms, and we would miscompile as if it could. This should fix SR-585.
Previously we would check TMF_UnwrappingOptional flag, which does not
stick with the constraint, so it would not always persist. Now, add a
new OptionalPayload locator element, which is more correct.
Fixes <rdar://problem/30429709>.
We previously penalized bindings to Any, and that resulted in
inappropriately rejecting solutions where we bind a decl that is
explicitly typed Any. That penalty was removed in
170dc8acd7, but that has led to a variety
of source compatibility issues.
So now, we'll reintroduce a penalty for Any-typed things, but instead of
penalizing bindings (which happen both because of explicitly-typed
values in the source, and implicitly due to attempting various types for
a particular type variable), penalize casts, which are always present in
some form in the source.
Thanks go to John for the suggestion.
Fixes
SR-3817 (aka rdar://problem/30311052)
SR-3786 (aka rdar://problem/30268529)
rdar://problem/29907555
This change is needed by a separate change I have that penalizes
conversions to Any. That change exposed a problem where we ended up
doing a direct lvalue-to-Any conversion without first loading as part of
an lvalue-to-rvalue conversion.
We should really only be doing most of these other conversions/fixes on
rvalues.
Unfortunately I don't know of a way to hit this without the other
change, and thus don't have a test case.
As a side note, this also helps some (perhaps most, but definitely not
all) of the exponential type inference cases involving arrays and
dictionaries. Unfortunately again, we don't currently have a testing
mechanism in place to ensure we don't regress those cases, and I don't
want to add a test that will completely hang every bot if it does
regress, so...*sad face*...no test case for that either.
We limit Optional-to-IUO as an implicit conversion to avoid making
common expressions ambiguous. However, this runs into trouble with
function-to-function conversions, which always look for a "Subtype"
relationship for their inputs and outputs. This is a conservative way
for Sema to avoid emitting conversions that SILGen cannot handle.
The problem case here is converting a closure with type '(Any!) ->
Void' to a value of type '(Any?) -> Void':
let f: ((Any?) -> Void) = { (arg: Any!) in }
This is clearly a safe conversion, since 'Any!' and 'Any?' have the
same representation at run time, but historically we've disallowed it
because of the above rules. However, in Swift 3.0 this particular case
was permitted, with the type checker deciding that the 'Any?' argument
to 'f' could first itself be put into an 'Any', then /that/ value
could go through a value-to-optional conversion to make 'Any!'.
Fortunately the emitted code didn't follow this incorrect conversion
path.
This patch doesn't even try to emulate the old behavior. Instead, it
just weakens the restriction on Optional-to-IUO via a new type
matching flag that only applies within the context of matching
function types.
We can consider opening up function conversions in Swift 4 to anything
that supports conversion---not just subtyping---now that SILGen knows
how to automatically reabstract most such things. But whether we do or
not, Optional/IUO is a special case.
https://bugs.swift.org/browse/SR-3758
Swift 3.0 allowed constructing an enum or calling a function-typed
property with multiple arguments even when a single argument of tuple
type was expected. Emulate that in Swift 3 mode by wrapping in an
extra level of parentheses when the situation comes up.
Last vestiges of fallout from SE-0110. Hopefully last, anyway. A nice
follow-up to this commit might be to /warn/ in Swift 3 mode when this
happens.
rdar://problem/30171399
When I refactored the handling of bridging conversions (e.g.,
valueType as? NSClassType), I broke the path that performed a bridging
conversion followed by a conversion to an existential, e.g.,
"some-bridged-value-type as CVarArg". Reinstate such use cases.
Fixes rdar://problem/30195862.
Without this, CSGen/CSSimplify and CSApply may have differing
opinions about whether e.g. a let property is settable, which
can lead to invalid ASTs.
Arguably, a better fix would be to remove the dependency on the
exact nested DC. For example, we could treat lets as settable
in all contexts and then just complain later about invalid
attempts to set them. Or we could change CSApply to directly
use the information it already has about how an l-value is used,
rather than trying to figure out whether it *might* be getting set.
But somehow, tracking a new piece of information through the
entire constraint system seems to be the more minimal change.
Fixes rdar://29810997.
Revert 7c665c105b because it results in a
much worse source compatibility regression than the one it was intended
to fix.
The problem is that it results in force-unwrapping IUOs, which can lead
to cases where we prefer type-checking solutions that choose methods
over properties where we used to choose properties. So for example a
collection literal like [x] will result in a collection with a method
named 'x' in it rather than a property named 'x'.
I'll be looking at other solutions which fix both the original
compatibility regression as well as retain the behavior in the new test
added here.
Fixes SR-3715 and rdar://problem/30176166.
1efafbcd9b restricted our classification
of various optional-related conversions (implicit forcing of IUOs,
optional-to-optional conversions, value-to-optional conversions) to
produce a single potential classification. However, in the presence of
type variables, we cannot always determine which particular conversion
restriction might apply. Prior to 1efafb, we produced too many
options; after 1efafb, we produced too few. Here, enumerate a more
bounded (but complete) set of potential conversions, taking into
account embedded type variables.
This is a better fix for rdar://problem/29977523 than simply reverting
1efafb, because it bounds the set of optional conversions we attempt.
This reapply's Doug's change d79ba781c6,
which had previously been applied on top of
1efafbcd9b, the latter of which resulted
in a source compatibility break.
This reverts commit 1efafbcd9b because
results in a regression in source compatibility with Swift 3.
It also adds a test demonstrating what was broken by the change.
I will take another look at fixing the exponential behavior that this
was attempting to fix.
Fixes rdar://problem/29977523.
In Swift 4 mode, no longer consider e.g. 'nsNumber as Int' or 'nsValue as NSRange' to be valid coercions. This would break compatibility with Swift 3, so in Swift 3 mode, accept the coercion, but *also* accept a checked cast without a warning, and raise a migration warning about the unchecked coercion.
Commit 170dc8acd7 removed a penalty that
we used to have for conversions to Any. In some unusual circumstances
not having that penalty can result in new amiguities where we should
have nothing ambiguous about an expression according to our type rules.
This change attempts to ensure that we make that less likely or
impossible by not allowing direct conversions from IUOs to Any (instead
forcing these to first be force-unchecked, leading to more expensive
solutions). We never should have allowed these conversions anyway,
independent of removing the penalty for conversions to Any.
This change is intentionally very narrow to avoid further potential
source breakage.
Fixes rdar://problem/29907555.
