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
Class constraints (spelled T: AnyObject) on generic types were not
getting checked on generic arguments. This appears to be a regression
introduced in Swift 4.0 with the removal of AnyObject, leading to a
fairly significant soundness hole that could produce crashers later
on.
Fixes SR-6841 / rdar://problem/36884025.
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.
Use this in places where we have a decl that is marked with the
ImplicitlyUnwrappedOptionalAttr so that we can distinguish in the
solver which decls need to be potentially unwrapped in order to type
check successfully.
It's probably harmless to record the ones for failures which later cause
us to back out in the solver, but it means we cannot easily set
breakpoints in places like recordFix and stop only in the places where
the fixes actually cause the solution to make progress.
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.
Fix collection subtyping relation in function argument position
by emiting special re-abstraction thunk with collection upcast.
Resolves: rdar://problem/35702810
We now store an entire OverloadChoice in the unviable candidates
list (which is used for error recovery), just like we store them
for viable candidates.
The additional information isn't used, so NFC.
conformsToProtocol() is the main way in which we check whether a given type
conforms to a given protocol. Extend it to check conditional requirements by
default, so that an unmodified caller will get the "does not conform" result
(with diagnostics when a location is present) rather than simply ignoring
the conditional requirements.
Some callers take responsibility for conditional requirements, e.g., to
push them into the constraint system. Allow those callers to opt out of
this checking, and do so wherever appropriate.
Fixes rdar://problem/35518088, where we were ignoring the conditional
requirements needed to verify that Equatable synthesis could be performed.
Using this constraint locator element, we can check when a failed
constraint is due to an unsatisfied conditional requirement of a
protocol conformance. Unfortunately, it's hard to turn this into
an actionable diagnostic right now.
Rather than wantonly dropping the conditional requirements when checking
for type erasure, add them in the same way we do for (e.g.) conformance
checking for generics. Fixes rdar://problem/35480860.
We added this hack to work around the use of context types within normal
protocol conformances, which created tautological constraint systems.
With the switch to interface types in normal protocol conformances, this
hack is no longer necessary.
When testing KeyPathApplication constraints, we would keep going after rejecting a concrete KeyPath application by trying PartialKeyPath and AnyKeyPath, even though that's not what we want, since any key path application expression can type check with an AnyKeyPath. We would then miscompile by building the AST such that we applied the mismatched key path expression directly to the base. We also didn't handle expressions where the base was a subtype of the key path's base type correctly—the conversion means the base can't be written through in this situation, and we hardcoded the concrete-to-existential case instead of handling general conversions. Fix these problems, and add an AST verifier for KeyPathApplicationExprs to help catch problems in the future. Fixes SR-6300 | rdar://problem/35368903.
Remove function-to-function type match score increase, which should only
happen contextually in presence of other restrictions, this used to fix
the case related to matching of arrays of functions with and w/e `throws`
as function parameters which used to be ambigious, and now handled by
collection-upcast conversion score.
Resolves: rdar://problem/35142121
Presence of some constraints (Subtype at least) requires a certain
contextual ranking of the type variables associated with them when
it comes to picking bindings, otherwise it might lead to no or
invalid solutions, because only a set of the bindings for the best
type variable is attempted.
Resolves: rdar://problem/22898292
Presence of some constraints (Subtype at least) requires a certain
contextual ranking of the type variables associated with them when
it comes to picking bindings, otherwise it might lead to no or
invalid solutions, because only a set of the bindings for the best
type variable is attempted.
Resolves: rdar://problem/22898292
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
This may not quite be NFC since the path for Subtype bindings checked
other conditions before this, but I believe this is the right thing to
do in all cases where we have two identical type vars.
The base mutability of storage is part of the signature, so be sure
to compute that during validation. Also, serialize it as part of
the storage declaration, and fix some places that synthesize
declarations to set it correctly.
The naming here might not be perfect as it's not the only place that we
bind types to typevars in matchTypes, but it is a step towards cleaning
things up a bit. I'll revisit naming after I get a better idea what
other common code there may be that can get factored out.
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
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
