When trying to diagnose ambigiuty with constraint system check if any of the
unresolved type variables are related to generic parameters, and if so
try to diagnose a problem based on the number of constraints associated with
each of the unresolved generic parameters.
Number of constraints related to a particular generic parameter
is significant indicator of the problem, because if there are
no constraints associated with it, that means it can't ever be resolved,
such helps to diagnose situations like: struct S<A, B> { init(_ a: A) {}}
because type B would have no constraints associated with it.
As an extension of SR-2208 apply contextual conversion failure checking
to all of the expressions diagnosed via FailureDiagnosis::visitApplyExpr.
Resolves <rdar://problem/28909024>.
The 'literalConformanceProto' field of
TypeVariableType::Implementation didn't take into account equivalence
classes of type variables. Eliminate it, and either look at the actual
expressions (for optimizing constraints during constraint generation)
or the actual constraints on a given type variable (for determining
whether to include optionals in the set of potential type variable
bindings).
(cherry picked from commit 6bdd9cfae5)
This reverts commit 6bdd9cfae5. This
commit *appears* to be breaking something in Dollar involving
inference with array literals and 'nil'; pull it back for more
investigation.
The 'literalConformanceProto' field of
TypeVariableType::Implementation didn't take into account equivalence
classes of type variables. Eliminate it, and either look at the actual
expressions (for optimizing constraints during constraint generation)
or the actual constraints on a given type variable (for determining
whether to include optionals in the set of potential type variable
bindings).
We had a few places that were performing ad hoc variants of
ConstraintSystem::getFixedTypeRecursive(); simplify it's interface so
we can use it everywhere consistently. Fixes rdar://problem/27261929.
Similar to “isTypeParameter,” this new entry point determines whether the type is a type variable or a nested type of a type thereof. The latter case isn’t actually formed yet, so this is NFC staging the trivial bits of this change.
In most places where we were checking "is<ErrorType>()", we now mean
"any error occurred". The few exceptions are in associated type
inference, code completion, and expression diagnostics, where we might
still work with partial errors.
This was almost identical to getMemberSubstitutions(), except
protocol and protocol extension members are not properly
supported.
Now that this method is no longer used by the ASTPrinter, there
are only two remaining usages, both trivially refactorable to
use better APIs.
There's a bit of a hack to deal with generic typealiases, but
overall this makes things more logical.
This is the last big refactoring before we can allow constrained
extensions to make generic parameters concrete. All that remains
is a small set of changes to SIL type lowering, and retooling
some diagnostics in Sema.
We were attempting to clean up stray type variables before creating a
new constraint system and moving forward with narrowing down the
typecheck failure, but we were failing to remove type variables for
interpolated strings.
Fix that, as well as removing them from TypeExpr's, and add an assert
that on exit from the pre-order visitor we don't have any type
variables (except for literals that aren't interpolated strings, which
I'm going to dig into further).
Fixes rdar://problem/27830834 and SR-2716.
We could probably make this even more general, but this specifically
avoids trying to insert an "as AnyObject" fix-it, which will now work
but probably produce an incorrect result. This comes up when working
with swift_newtype wrappers of CF types being passed to CFTypeRef
parameters.
rdar://problem/26678862
For example, if someone tries to use the newly-generic type Cache,
from Foundation:
var cache = Cache()
they'll now get a fix-it to substitute the default generic parameters:
var cache = Cache<AnyObject, AnyObject>()
The rules for choosing this placeholder type are based on constraints
and won't be right 100% of the time, but they should be reasonable.
(In particular, constraints on associated types are ignored.)
In cases where there's no one concrete type that will work, an Xcode-
style placeholder is inserted instead.
- An unconstrained generic parameter defaults to 'Any'.
- A superclass-constrained parameter defaults to that class,
e.g. 'UIView'.
- A parameter constrained to a single @objc protocol (or to AnyObject)
defaults to that protocol, e.g. 'NSCoding'.
- Anything else gets a placeholder using the generic parameter's name
and protocol composition syntax.
rdar://problem/27087345
The fixits call back into the type checker via typeCheckCheckedCast(),
which sets up a new constraint system. As a result we would hit
assertions by introducing type variables from a previous "generation".
It seems that if we bail out of this code path altogether, we get a
better diagnostic -- in the provided test, it complains about an
ambiguous member to '.value', rather than not being able to convert
_? to V?.
Fixes <https://bugs.swift.org/browse/SR-2592>.
(by making it a normal argument with a label and not a trailing
closure)
Diagnostic part of rdar://problem/25607552. A later commit will keep
us from getting in this situation quite so much when default arguments
are involved.
In CSDiag.cpp I previously added a helper, isCastToTypedPointer(), to emit an
diagnostics explaining how to migrate UnsafeRawPointer conversion. This commit
broadens that diagnostic to handle Optional<UnsafeRawPointer>.
rdar:27894255 [3.0 migration] Emit an additional note for conversion
* [FixCode] Add diagnosis/fixit to help users deal with BooleanType's removal.
Due to migration reasons, types used to conform to BooleanType, which
must contain a member var 'boolValue', now does not convert to Bool. This patch
adds a specific diagnosis/fixit to explicitly invoke 'boolValue' to please the
context types.
* Address Jordan's code review comments.
We saw manual migration is necessary on these cases to add 'as Type'. This patch starts
to issue compiler fixits on return statement and initialization just like in other type-mismatch
cases.
This commit built upon the work of Pull Request 3895. Apart from the
work to make the following work
```swift
let f: (Int, Int) -> Void = { x in } // this is now an error
```
This patch also implement the part 2 mentioned in the #3895
```swift
let g: ((Int, Int)) -> Void = { y in } // y should have type (Int, Int)
```
...not just those where the functions match otherwise. This allows the
fix-it to be provided in cases where the closure being passed is a
subtype, or when there are generics involved. Yes, the '@escaping'
might not be the only issue, but it will need to get fixed, and
probably independently of anything else that's going on (except
perhaps calling the wrong function).
rdar://problem/27729540
