Number of defaults is a fallback condition if there are no other
differences, but pontential bindings which are literal should always
be ranked lower than anything else because there is a higher chance
that such bindings are wrong because their full set might not have
been resolved yet.
Resolves: rdar://problem/39616039
Currently we have this non-optimal behavior in `contractEdges` where
for every type variable it gathers constraints for its whole equivalence
class before checking if any are "contractable", instead constraints
could be gathered/filtered once which removes a lot of useless work.
Replace two prominent uses of SubstitutionList, in ConcreteDeclRef and
Witness, with SubstitutionMap. Deal with the myriad places where we
now have substitution maps and need substitution lists (or vice versa)
caused by this change.
Overall, removes ~50 explicit uses of SubstitutionList (of ~400).
Given something like `max(1, 2)` inside a type that conforms to Sequence, this
allows the compiler to consider Swift.max as well as the two methods with that
name on Sequence.
This disappeared in the rework of IUOs but is needed when we have
multiple potential solutions involving different sets of overloads or
type bindings.
Fixes rdar://problem/37475971.
Many (perhaps most?) calls to createTypeVariable explicitly pass 0 for
options. This change just defaults the parameter to 0 and removes all
the explicit 0's in the code.
They can show up when re-typechecking via diag or code-completion and were
only being sanitized out in one place in CSDiag. Moved that logic into
SanitizeExpr.
Resolves rdar://problem/38149042
Don't attempt to store literal bindings directly to `PotentialBindings`
since they might get superseded by non-literal bindings deduced from
other constraints, also don't attempt to check literal protocol conformance
on type variables or member types since such types would always end-up
returning trivial conformance which results in removal of viable literal types.
Resolves: rdar://problem/38535743
Such overloads are not going to result in viable solutions anyway,
so it makes sense to attempt them only if solver failed to deduce
proper solution.
Helps to improve type-checking performance of operators which have
multiple unavailable overloads for compatibility reasons.
Some of the expressions call into `typeCheckExpressionShallow` while trying to
apply solutions, we need to respect the fact that sub-expressions might be
already properly type-checked while propagating l-value access kind.
Resolves: rdar://problem/38309176
Move all the code specific to dealing with relational constraints out
into a separate function.
I expect to do more refactoring here so this is likely not the final
form for this code - just one step in the direction of breaking things
down into smaller logical pieces.
Attempt to use potential bindings inferred for related types variables
discoverable through 'subtype' constraints, this helps to build a
more precise bindings domain for each type variable.
Resolves: rdar://problem/38159133
* 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!
Add dumpers to dump from the constraint system type cache.
There isn't a TypeLoc dumper per-se, but the places where we dump
TypeLocs in expression dumping will read the type from the cache.
This is useful for explicit casts and type expressions, where
type loc and expression types might be different, and allows
constraint solver to avoid setting opened types to expressions
which resolves multiple crashes.
With all else equal prioritize bindings with fewer defaultable types,
which always gets us closer to solution since defaultable bindings
mostly come from the collections and could be checked at the end.
This also makes sure that solver not as aggresive at assigning bindings
to trailing closures and allows solver to consider types which come
from inside the closure.
Resolves: rdar://problem/37290898
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
Stop creating ImplicitlyUnwrappedOptional<T> so that we can remove it
from the type system.
Enable the code that generates disjunctions for Optional<T> and
rewrites expressions based on the original declared type being 'T!'.
Most of the changes supporting this were previously merged to master,
but some things were difficult to merge to master without actually
removing IUOs from the type system:
- Dynamic member lookup and dynamic subscripting
- Changes to ensure the bridging peephole still works
Past commits have attempted to retain as much fidelity with how we
were printing things as possible. There are some cases where we still
are not printing things the same way:
- In diagnostics we will print '?' rather than '!'
- Some SourceKit and Code Completion output where we print a Type
rather than Decl.
Things like module printing via swift-ide-test attempt to print '!'
any place that we now have Optional types that were declared as IUOs.
There are some diagnostics regressions related to the fact that we can
no longer "look through" IUOs. For the same reason some output and
functionality changes in Code Completion. I have an idea of how we can
restore these, and have opened a bug to investigate doing so.
There are some small source compatibility breaks that result from
this change:
- Results of dynamic lookup that are themselves declared IUO can in
rare circumstances be inferred differently. This shows up in
test/ClangImporter/objc_parse.swift, where we have
var optStr = obj.nsstringProperty
Rather than inferring optStr to be 'String!?', we now infer this to
be 'String??', which is in line with the expectations of SE-0054.
The fact that we were only inferring the outermost IUO to be an
Optional in Swift 4 was a result of the incomplete implementation of
SE-0054 as opposed to a particular design. This should rarely cause
problems since in the common-case of actually using the property rather
than just assigning it to a value with inferred type, we will behave
the same way.
- Overloading functions with inout parameters strictly by a difference
in optionality (i.e. Optional<T> vs. ImplicitlyUnwrappedOptional<T>)
will result in an error rather than the diagnostic that was added
in Swift 4.1.
- Any place where '!' was being used where it wasn't supposed to be
allowed by SE-0054 will now treat the '!' as if it were '?'.
Swift 4.1 generates warnings for these saying that putting '!'
in that location is deprecated. These locations include for example
typealiases or any place where '!' is nested in another type like
`Int!?` or `[Int!]`.
This commit effectively means ImplicitlyUnwrappedOptional<T> is no
longer part of the type system, although I haven't actually removed
all of the code dealing with it yet.
ImplicitlyUnwrappedOptional<T> is is dead, long live implicitly
unwrapped Optional<T>!
Resolves rdar://problem/33272674.
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
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.
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.
This reverts commit 2f80af15ec.
I expected this to have no effect, but it results in one of the
expression type checker tests taking longer, so that test was disabled.
This commit also re-enables the test since it now passes again.
Instead of binding collection types directly let's try to
bind using temporary type variables substituted for element
types, that's going to ensure that subtype relationship is
always preserved.
Resolves: rdar://problem/35541153
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.
