Also, stop context type analysis at outer most expression that matches
the position. It seems that that produces more appropriate results.
rdar://problem/30103287
For:
class MyClass {
func foo(x: SomeType)
func foo(x: OtherType)
}
func test(obj: MyClass) {
obj.foo(x: <HERE>)
}
Type checker doesn't keep overloaded choices for 'obj.foo' in the AST
after typechecking. Code completion need to lookup members to collect
possible parameter types.
in unresolved member completion. e.g.
struct Node {
typealias Child = Node
init(children: [Child]) {}
}
let node: Node = .#^COMPLETE^#
This used to emit `.init(children:)` and `.Child(children:)`.
Implement 'get', 'set', 'willSet', 'didSet' completion at the beginning
of accessor position.
var value: Ty {
<HERE> // 'get', 'set', 'willSet' and 'didSet' along with normal
// completion.
}
var value: Ty {
get { return ... }
<HERE> // 'get', 'set', 'willSet' and 'didSet' only.
}
rdar://problem/20957182
It is possible for the SIL optimizers, IRGen, etc. to request information
from the AST that only the type checker can provide, but the type checker
is typically torn down after the “type checking” phase. This can lead to
various crashes late in the compilation cycle.
Keep the type checker instance around as long as the ASTContext is alive
or until someone asks for it to be destroyed.
Fixes SR-285 / rdar://problem/23677338.
(and TupleExpr at non-call argument position).
Now, unresolved member completion in array literal should work.
Also, Don't calculate convertibility to 'Any' type. That would be a
noise to type relation because anything is convertible to 'Any'.
rdar://problem/43302814
Previously, local decls in trailing closure didn't show up if the
closure had preceding arguments and the completion was triggered at
beginning position of expression context. like:
funcName(x: arg1) {
var localVar = 12
if <HERE>
}
The completion mode used to be overwritten in 'completeCallArg()' which
is called from 'parseExprCallSuffix(). We should detect completion for
immediate argument position in 'parseExprList()'.
rdar://problem/41869885
Added the 'Module::getPrecedenceGroups' API to separate precedence group lookup
from 'Module::lookupVisibleDecls', which together with 'FileUnit::lookupVisibleDecls',
to which the former is forwarded, are expected to look up only 'ValueDecl'. In particular, this
prevents completions like Module.PrecedenceGroup.
Before checking type relation between candidate types and expected
types. In normal compilation, this removal is done in CSGen. However,
since code-completion directly uses Constraint System, we have to
manually remove argument labels before checking convertibility.
We can remove argument labels unconditionally because function types as
as value cannot have argument labels. (i.e. `let f: (a: Int) -> Int` is
illegal). That means, expected types shouldn't have any argument labels.
This fixes regression revealed in 5e75b1ad3b
rdar://problem/41496748
* Handle generic base types
* Suggest '.some' and '.none' for optional types
* Don't look through too many parameter lists for function types
* Include members with convertible type result
rdar://problem/44803439
We need to look through the optional and find the members of T when
doing completion in Optional<T>.
let x: Foo? = .foo
We still don't correctly complete .some/.none, which requires
reconciling the unbound generic type we get from the decl with the real
bound generic type.
rdar://44767478
* [InterfaceGen] Remove #ifs from default args
This patch removes all #if configs form the bodies of default arguments,
which can contain multiline closures, while preserving the bodies of the
clauses that are active.
This code is generalized and should "just work" for inlinable function
bodies, which will come in a later patch.
* Address review comments
* Fix and test CharSourceRange.overlaps
* Fix CharSourceRange::print to respect half-open ranges
CompletionLookup::IsStaticMetatype was not explicitly initialized during construction, so it could sometimes have garbage values. This caused UBSan to error out on IDE/complete_enum_elements.swift and IDE/complete_unresolved_members.swift.
* Handle completion in 'parseExprKeyPath()' instead of
'parseExprPostfixSuffix()'.
* Fix a crash for implicit type keypath. e.g. '\.path.<complete>'. (SR-8042).
* Use 'completeExprKeyPath()' callback.
* Implement completion without '.'. e.g. '\Ty.path<complete>'
* Improved handling for 'subscript' in completion.
* Improved handling for optional unwrapping in completion.
https://bugs.swift.org/browse/SR-8042
rdar://problem/41262612
* Consolidate CompletionKind::KeyPathExpr and CompletionKind::KeyPathExprDot
to CompletionKind::KeyPathExprObjC
* Make completeKeyPath() to receive DotLoc.
- 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.
Unresolved type attached to expressions may fail re-typechecking.
Also, disallow unresolved type in typeCheckCompletionSequence(). It doesn't
provide useful completions to developers.
rdar://problem/41224316
A significant chunk of the handling for LookupKind::ValueExpr
was duplicated in the handling for the ValueInDeclContext and
ImportFromModule cases. Use a fall through to unify the
code paths here.
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.
Using dummy UnresolvedMemberExpr doesn't give us much benefit. Instead, use
CodeCompletionExpr which is type checked as type variable so can use
CodeCompletionTypeContextAnalyzer to infer context types.
This way, we can eliminate most of special logic for UnresolvedMember.
rdar://problem/39098974
