If a cross-import overlay shadows another module and has a name starting with
'_', don't present that overlay in places where module name completions are
offered and present symbols comining from that module as if they came from
the shadowed module instead.
Resolves rdar://problem/59445688
Replace it with the "legacy semantic queries" bit. The remaining client
of this bit is SourceKit, which appears to require this bit be set
conditionally so certain semantic property wrapper requests return
a sentinel value.
We should migrate these requests to a syntactic interface as soon as
possible.
rdar://60516325
- In member completions, when 'callAsFunction' decls are found, suggest
call patterns
- In call pattern completions, fallback to search 'callAsFunction' if
the base type is not a function type
rdar://problem/59792682
instead of the pre-typechecked type and the referenced decl in the AST
so that we can suggests all overloads even if it happen to be
typechecked to a method. For example
struct MyType {
func foo() {}
func foo(_ int: Int) {}
func foo(name: String, value: String) {}
}
func test(val: MyType) {
value.foo(#^COMPLETE^#)
}
In this case, the call is typechecked to 'MyType.foo(_:)', but we want
to suggest all overloads.
rdar://problem/59285399
When a “separately imported overlay” is added to a SourceFile, two things happen:
1. The direct import of the underlying module is removed from getImports*() by default. It is only visible if the caller passes ImportFilterKind:: ShadowedBySeparateOverlay. This means that non-module-scoped lookups will search _OverlayModule before searching its re-export UnderlyingModule, allowing it to shadow underlying declarations.
2. When you ask for lookupInModule() to look in the underlying module in that source file, it looks in the overlays instead. This means that UnderlyingModule.foo() can find declarations in _OverlayModule.
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.
