If fixes are allowed let solver record missing protocol conformance
requirements and assume that `conformsTo` constraint is successfully
solved, this helps to diagnose such errors without involving
heavy-weight expression based diagnostics.
Resolves: rdar://problem/40537858
While inferring avoid associating type variables with closure
parameters, use cache instead and only set types when everything
is properly type-checked, this avoids multiple problems one of
them - leaking type variables outside of constraint system they
belong to.
Most of the use-cases of `gatherConstraints` require filtering
at least based on the constraint kind that caller is interested in,
so instead of returning unrelated results and asking caller to
filter separately, let's add that functionality directly to
`gatherConstraints`.
Since it's possible to find the same constraint through two different
but equivalent type variables, let's use a set to store constraints
instead of a vector to avoid processing the same constraint multiple
times.
This builds on initial commit which added `RelabelArguments` fix
to the solver that only supported `missingLabels` at that moment,
but now it supports all three posibilities - missing/extraneous and
incorrect labels.
Let the solver disregard missing argument labels and record correct
ones, so such problem could be diagnosed later on iff there were no
other more serious failures.
* Improve label mismatch callback:
- Split "missing label" callback into 3 - missing, extraneous, incorrect (with typo(s));
- Allow label callbacks to indicate if it's a fatal error or not;
* Improve matching of the variadic parameters;
* Improve matching of the parameters with defaults;
* Try to look for an argument with matching label before fallback to
forced claming (if allowed).
...unless the argument is an `Any?`, in which case we prefer `f(_: Any?)`.
This change also results in our selecting f<T>(_: T) over f(_:
Any). Coercing with 'as Any' makes it possible to explicitly select
the Any overload. Previously there was no way to select the generic
overload.
Treat non-optional generic parameters as being more specialized than
optional generic parameters, and penalize any solutions that involve
generic arguments that are themselves Optional.
By doing these things, we can remove the special-cased code for the
two overloads of '??' in the stdlib, instead treating the (T?, T)
overload as better than the (T?, T?) overload except where a user
actually passes an optionally-typed value as the second parameter.
Fixes: rdar://problem/19748710
Introduce a new fix kind into the constraint solver to cover unwrapping the base
of a member access so we can refer to the a member of the unwrapped base.
Wire this fix kind to the just-added diagnostic that suggests either the
chaining ‘?’ or the force-unwrap ‘!’ via separate, descriptive Fix-Its.
Example:
error: value of optional type 'X?' must be unwrapped to refer to member 'f' of wrapped base type 'X'
let _: Int = x.f()
^
note: chain the optional using '?' to access member 'f' only for non-'nil' base values
let _: Int = x.f()
^
?
note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
let _: Int = x.f()
^
!
Before this, we would sometimes get a Fix-It for just ‘?’ and sometimes get a Fix-It for the
coalescing ‘??’, neither of which is likely to be right.
More work on rdar://problem/42081852.
More groundwork for protocols with superclass constraints.
In several places we need to distinguish between existential
types that have a superclass term (MyClass & Proto) and
existential types containing a protocol with a superclass
constraint.
This is similar to how I can write 'AnyObject & Proto', or
write 'Proto1 & Proto2' where Proto1 has an ': AnyObject'
in its inheritance clause.
Note that some of the usages will be revisited later as
I do more refactoring and testing. This is just a first pass.
In Swift 4, constructors had the same name as properties,
methods and enum cases named `init`. This meant that you
could use constructor syntax to call such a member, which
caused some confusing behavior.
Recently I added a special declname for `init` so that
constructors have unique names distinct from any name you
can spell, and "foo.init" syntax would look for a member
with the special name rather than one named `init`.
Unfortunately people actually had code where they defined
members named `init` and then use them via normal member
lookup syntax, like this:
enum E {
case `init`
}
let e: E = E.init
So to maintain backward compatibility, hack member lookup
to also find members named `init` when looking up the special
declname for constructors.
The workaround is only enabled in Swift 4 and 4.2 mode;
in Swift 5 mode you are expected to write "foo.`init`" to access
non-constructor members named `init`.
Fixes <rdar://problem/38682258>.
Refactor the interface to return a bit vector. Along the way, fix up
the callers and remove some dead usages of the defaults information
that were copied and pasted around Sema.
Since member lookup doesn't check requirements
it might sometimes return types which are not
visible in the current context e.g. typealias
defined in constrained extension, substitution
of which might produce error type for base, so
assignement should thead lightly and just fail
if it encounters such types.
Resolves: rdar://problem/39931339
Resolves: SR-5013
Only two more of these exist
1) CSGen's formation of @lvalue -> inout conversion constraints
2) WritableKeyPath's checking rules
Both can be eliminated but will require more refactoring.
8271c1a removed the last hacky usage of ArrayElementType,
leaving behind just the @lvalue-to-inout conversions. Rename
the locator path element to reflect this and do a bit of cleanup on the
unrelated-but-near-enough other hack RValueAdjustment.
Disallow implicit conversion or arguments from Array, String, and
InOut (formed by &) to pointer types if the argument is for an
@autoclosure parameter.
These conversions were really only intended to be used for C/ObjC
interop, and in some contexts like autoclosures they are not safe.
Fixes: rdar://problem/31538995
We inadvertantly allowed this in the past, so continue to do so when
compiling in Swift 3/4 mode to avoid suddenly breaking existing code.
The diagnostic here is pretty bad, and I've opened issues for that as
well as providing some kind of deprecation warning for this so that
even under Swift 3/4 mode we alert users that this is unsupported.
rdar://problem/39802797
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.
`AbstractStorageDecl::isSettable` by itself doesn't account for access control, so we need to check `isSetterAccessibleFrom` as well. Furthermore, key paths should not get the special context-sensitive privileges direct accesses do, such as initializers being able to assign into `let` properties. Fix the type checking logic here to only create a statically writable KeyPath value when the referenced declaration has a setter visible independent of current context. Fixes SR-6667 | rdar://problem/36257266.
That hack resulted in already matching argument and parameter to end
up not matching in this case.
Fixes https://bugs.swift.org/browse/SR-7191
and rdar://problem/38798063
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.
