While trying to find a fixed type for a given type variable, check if
it has representative and if it does, reflect that in the returned type.
Resolves: rdar://problem/34670592
CSDiag was misinterpreting the result of checkGenericArguments().
A result of SubstitutionFailure does not mean a diagnostic was
emitted, only a result of Failure means that. This fixes a case
where we did not emit a diagnostic, result in a crash on invalid.
The diagnostic is still poor, but that's better than crashing.
Fixes <https://bugs.swift.org/browse/SR-5932>,
<rdar://problem/34522739>.
For the moment, update the sole caller to not infer Any in cases where
neither argument was Any. This is in part because not all the cases are
handled here and the result of inferring Any will be to miss appropriate
bindings in certain cases. It is also in part because by inferring Any
we may end up deferring diagnostics until later in a function, which may
result in very hard to understand diagnostics for users.
This will be revisted once all the cases are properly handled here.
Currently edge related to the parameter bindings is contracted
without properly checking if newly created equivalence class has
the same inout & l-value requirements. This patch improves the
situation by disallowing contraction of the edges related to parameter
binding constraint where left-hand side has `inout` attribute set.
Such guarantees that parameter can get `inout` type assigned when
argument gets `l-value` type.
Resolves: rdar://problem/33429010
Since we no longer allow constraction of subtype constraints, workaround
which exists in `matchTypes`, for situations where left-hand side of such
constraint is going to be wrapped in `inout` type, is no longer required.
Resolves: rdar://problem/34137342, rdar://problem/34136625
Use this to remove the last bit of the hack to suppres noescape on setter
arguments. Add a more comprehensive test of noescape's interaction with
accessors.
The etymology of these terms isn't about race, but "black" = "blocked"
and "white" = "allowed" isn't really a good look these days. In most
cases we weren't using these terms particularly precisely anyway, so
the rephrasing is actually an improvement.
Split out the things that are really specific to Swift 3 into a new
closures_swift3.swift.
In the process I found that two things that should compile without error
under -swift-version 4 do not, so those tests are currently in
closures_swift3.swift and I have opened new bugs for the issues:
https://bugs.swift.org/browse/SR-5791https://bugs.swift.org/browse/SR-5792
If we allow the right-hand type to be bound first, it can artificially
limit the options for the left-hand side, so attempt to delay binding of
the right-hand side types until after we've chosen something for the
left-hand side.
The test here will not fail without this change, but will fail without
this change if the ConstraintGraph.cpp changes from @xedin's edge
contraction patch (https://github.com/apple/swift/pull/11118) are
applied.
When search for potential bindings for the given type variable
encounters `DynamicTypeOf` constraint, its validation should use
representative type variable of the left-hand side instead of
direct comparison.
When trying to find bindings let's avoid type variables which
represent left-hand side of the `DynamicTypeOf` constraint,
because such type variables might be (implicitly) convertible to
[existential] metatype, but at the same time bound to something else
(e.g. Any), which fails when solver tries to simplify `DynamicTypeOf`
constraint itself.
In diagnoseUnintendedOptionalBehavior, guard against recursing into
non-single-expression closures. If we recurse into these, we can end
up hitting malformed ASTs that we do not expect. These happen when we
successfully type-check the code outside of the closure, but the
closure body has errors.
There are potentially other similar issues in other miscellaneous
diagnostics walks.
I opened https://bugs.swift.org/browse/SR-5758 to remind us to review
these and ensure they do not have similar issues.
Previously, the failure diagnosis visitor would
default to the generic expr walk which would wind
up type checking the closure body and calling it a day.
Walk into the closure of a capture list expression to
emit better diagnostics.
A regression test for SR-5747 is added.
Limit the scope of the performance hacks which currently exist in the
solver even further by disallowing it to skip generic overlaods or stop
in case when previous solutions involve unavailable overloads, which
otherwise might lead to producing incorrect overall solutions.
We can only coerce metatypes covariantly but bridging
always requires an unrelated metatype cast. When
performing member lookup, especially unqualified member
lookup, disregard static members from bridged types entirely.
See SR-5670 and rdar://problem/33830526
`LinkedExprAnalyzer` is not always precise in collecting types of expressions,
so let's not try to impose anything upon linked operator expressions, which are
"mergable", except actually merging argument/result types together to help
constraint solver.
Resolves: rdar://problem/27700622
Recently TupleTypeElt was changed to add an inout bit. It is no
longer valid to construct tuple types whose elements have InOutType,
and instead the flag on the element must be set instead.
Update diagnoseImplicitSelfErrors() for the new convention.
Fixes the only remaining crash in the test case from <rdar://19569255>,
but the original issue were fixed long ago.
While trying to diagnose problems with ternary/if statements don't
allow clauses, when type-checked separately, to have unresolved type
variables because that doesn't help to find errors.
Currently `visitAssignExpr` always attempts to use type
derived from destination as a contextual type for assignment
source type-checking, which doesn't always lead to better
results.
Resolves: SR-5081
Fixes a problem related to presence of InOutType in function parameters
which diagnostics related to generic parameter requirements didn't handle
correctly, and improves diagnostics for unsatisfied generic requirements
in operator applications, which we didn't attempt to diagnose at all.
Resolves: rdar://problem/33477726
