Creating accessors for a storage declaration within validateDecl() caused
circular dependencies detected by the request-evaluator. Separate out
accessor creation to break the dependency.
Fixes SR-8656 / rdar://problem/43951634.
Now that function types cannot have a naked type variable as
their input type it's no longer possible to have an unsolved
ArgumentTupleConversion constraint, so we can bypass most of
the logic in matchTypes() and call matchCallArguments() instead.
Previously we would generate the following constraint here, where
'index' and 'output' are concrete types and $input is a type
variable:
- ValueMember(base, $input -> output)
- ArgumentTupleConversion(index, $input)
The problem is that we built a function type where the entire input
was a type variable, which would then bind to an argument list.
We could instead generate this constraint:
- ValueMember(base, $member)
- ApplicableFunction(index -> output, $member)
I also had to redo how keypaths map locators back to key path
components. Previously the ArgumentTupleConversion was created
with a locator ending in KeyPathComponent.
Now the ApplicableFunction is created with this locator, which means
the argument match is performed with a locator ending in
ApplyArgument.
A consequence of this is that the SubscriptIndex and SubscriptResult
locator path elements are no longer used, so remove them.
This requires various mechanical changes in places we look at
locators to handle this change. Should be NFC.
I needed this for materializeForSet remission, but it makes inherited
variadic initializers work, too.
I tried to make this a reasonable starting point for a real language
feature. Here's what's still missing:
- syntax
- semantic restrictions to ensure that the expression isn't written in
invalid places or arbitrarily converted
- SILGen support for expansions that aren't the only variadic argument
rdar://16331406
There is no longer any reason to attach solution to `ConstraintFix`
because solution applied to the constraint system before any of the
related fixes are diagnosed, so instead let's attach `ConstraintSystem`
to `ConstraintFix` directly, because it would have all of the required
information.
This makes it easier to grep for and eventually remove the
remaining usages.
It also allows you to write FunctionType::get({}, ...) to call the
ArrayRef overload empty parameter list, instead of picking the Type
overload and calling it with an empty Type() value.
While I"m at it, in a few places instead of renaming just clean up
usages where it was completely mechanical to do so.
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
Rather than validating the signature of any declaration found by
name lookup, first check whether there is a collision on the full name
of the declaration. This should result in fewer declaration validations.
That is, don't look through InOutType anymore, and update callers to
call getInOutObjectType() as well (or not, where it was obvious to me
that InOutType could not appear).
This surfaces more remaining uses of getInOutObjectType() directly.
This is a legacy holdover from when tuple types had default
arguments, and also the constraint solver's matching of function
types pre-SE-0110.
Well, move the last live usage to CSDiag, where it can die a slow
painful death over time. The other usages were not doing anything.
This either became dead shortly after the removal of Swift 3
compatibility mode from the constraint solver, or even earlier.
Note that the code completion test change is actually correct
because (Any) -> () is not convertible to () -> () in the
language.
In some cases, such as when pushing a collection conversion down to per-element conversions, we'll coerce a subtype metatype to AnyObject, as in:
```
func f(_: [AnyObject]) {}
f([NSString.self, NSObject.self]) // Type checks as [NSObject.Type] converted to [AnyObject]
```
and only record the restriction kinds used in the indirect steps NSString -> NSObject and NSObject.Type -> AnyObject without recording the jump from NSString.Type to AnyObject. coerceToType ought to apply this subtyping rule even without such a hint, though, since the restriction kind is intended only as an optimization. Fixes rdar://problem/42666956 .
Aim of this new diagnostic abstraction is to encapsulate each
individual failure into its own class with some shared base.
Good example of this - diagnostics related to generic requirement
failures, where each kind (conformance, same-type etc.) has
some specific logic e.g. diagnostic message but the all share
the same traits like affected declaration/requirement.
Since information comes from `Solution` anyway, it's good to have
that logic localized, but it's also useful for diagnostics based on
fixes attached to solutions.
