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.
The change to roll back a part of SE-0110 to allow multi-argument
functions to be passed in places where functions taking a tuple are
expected resulted in a regression in some cases where the fix would
strip off the last ParenType from single-argument functions.
Instead of stripping off parens from both function types we're trying to
match when they both have them, strip off none. This ensures that we
don't get summarily rejected in the nested matchTypes call by other
SE-0110-related code that bails if the two types do not have the same
"parenness".
Fixes rdar://problem/33043106 / SR-5387.
We want the type of a KeyPathExpr to be the specific *KeyPath<T, U> subclass appropriate for the literal, with upcasts to a more general contextual type, since we rely on that invariant elsewhere to extract the base and projected value types. Fixes SR-5008 | rdar://problem/32395076.
Change the fix-it to move the argument to its correct location in one go. This happens by removing it from one location and inserting it in the other (as opposed to the original implementation which swapped one argument with the preceding one). The commas separating the arguments are adjusted to match the moved argument.
Add new tests for reordering regular arguments, variadic arguments, and function arguments.
Resolves: SR-4715 rdar://problem/31849281
