Now
* NotApplicable: The result is not relevant for type relation (e.g.
keywords, and overloads)
* Unknown: the relation was not calculated (e.g. cached results), or the
context type is unknown.
* Invalid: The result type is invalid for this context (i.e. 'Void' for
non-'Void' context)
* Unrelated: The result type has no relation to the context type
* Convertible: The result type is convertible to the context type
* Identical: The result type is identical to the context type
in override completion. As per SE-0244:
> Associated type inference can only infer an opaque result type for a
> non-generic requirement, because the opaque type is parameterized by
> the function's own generic arguments
instead of AssociatedTypeDecl::getInherited() when checking if the
return type should be suggested as "opaque result type" in override
completion.
AssociatedTypeDecl::getInherited() is not serialized. So if the protocol
is declared in a module, it was never suggested as 'some' result.
rdar://problem/57245073
Well, this does nothing. It just set the parser position twice and calls
the consumer's 'handleResults()' without any reason.
It seems it was intended to be a "fallback" completion, but it was never
implemented properly. So just remove it for now.
rdar://problem/58102910
Replaces `ComponentIdentTypeRepr::getIdentifier()` and `getIdLoc()` with `getNameRef()` and `getNameLoc()`, which use `DeclName` and `DeclNameRef` respectively.
Previously, property names are hidden in the whole range of the
declarations. Now, it's only hidden in its own initializer range.
rdar://problem/49697202
In override completion, we didn't use to emit 'class var' with the initial
expression. However, having initial expression does not have any bearing
on whether the declaration is overridable or not.
- Use `performParseAndResolveImportsOnly()` to invoke the frontend
- Do `bindExtensions()` in `ide::typeCheckContextUntil()`
- Typecheck preceding `TopLevelCodeDecl`s only if the compleiton is in
a `TopLevelCodeDecl`
- Other related tweaks
rdar://problem/56636747
This seems more correct than OtherModule, and means they're treated as
low-priority results for the session-based completion APIs. With default
options that means won't be shown in global completion results but will be
once there's some matching filter text. It also sorts them below any symbols
that actually come from other modules, which is desirable, since most symbols
don't need to be module qualified.
The SemanticContextKind change doesn't seem to affect Xcode's handling of the
results.
ProtocolConformanceRef already has an invalid state. Drop all of the
uses of Optional<ProtocolConformanceRef> and just use
ProtocolConformanceRef::forInvalid() to represent it. Mechanically
translate all of the callers and callsites to use this new
representation.
Structurally prevent a number of common anti-patterns involving generic
signatures by separating the interface into GenericSignature and the
implementation into GenericSignatureBase. In particular, this allows
the comparison operators to be deleted which forces callers to
canonicalize the signature or ask to compare pointers explicitly.
To represent a type with code completion.
type? '.'? <code-completion-token>
This is "parser only" node which is not exposed to SwiftSyntax.
Using this, defer to set the parsed type to code-completion callbacks.
Now that the generic signature is computable on demand, this predicate is doubly useless. All of the callers intended to ask "hasInterfaceType" anyways.
This simplifies the code and prevents an assertion failure this code was
hitting computing the type relations between the result types and what it
determined as the expected type.
Resolves rdar://problem/53958454
