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
Suppose you have this protocol:
protocol P {
typealias A = Int
typealias B = Self
}
Clearly, 'P.B' does not make sense, because then the type parameter
would "leak out" of the existential container. However, 'P.A' is totally
fine, it just means 'Int'.
Previously, we would allow 'P.A' in type context, and diagnose on 'P.B'.
However, due to an oversight, neither one was allowed in expression
context, so for example you could not write 'P.A.self', even though
that should just mean 'Int.self'.
Fix this by generalizing performMemberLookup(), and fix up some
diagnostics to be more specific when something is wrong -- we want
to avoid talking about typealiases as 'static members', since that
doesn't really make much sense.
Fixes <https://bugs.swift.org/browse/SR-2314>.
* [FixCode] Add a fixit to help users migrate to Swift 3 name convention of enum cases. rdar://26887735
When users' referring to a enum case with a wrong name and we can find a correct enum case whose name
differs from the wrong name only in capitalization, we replace the wrong name with the correct one.
* Addressing Argyrios' code review comments. NFC
* [test] Update existing test.
* Grammatical polish suggested by @CodaFi.
Suggest a fix-it for unqualified references to all static members
from instance context, not just enum elements.
Also, fix a small problem with the fix-it for replacing protocol
names with 'Self' inside extension bodies -- we didn't handle nested
functions properly.
