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
When a type variable binds to an (unresolved) dependent member type,
it prevents us from inferring the type variable and adds no useful
information to the system. Refuse to bind type variables to dependent
member types.
Fixes rdar://problem/32697033.
There was an oversight in the exception that was added to SE-0110 to
maintain compatibility for closure arguments. We were not allowing
optional injection to happen for the closure being passed in, so things
like:
func test(_ fn: ((Int, Int))->()) {}
test { x, y in }
worked, but
func test(_ fn: (((Int, Int))->())?) {}
test { x, y in }
did not.
Fixes SR-5433 (rdar://problem/33239714).
Special DeclNames represent names that do not have an identifier in the
surface language. This implies serializing the information about whether
a name is special together with its identifier (if it is not special)
in both the module file and the swift lookup table.
