* 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
* Don't need to look for CodeCompletionExpr. It's wrong anyway because
what we are looking for is not neccessarily a 'CodeCompletionExpr'.
* Use getElementLoc(i).isValid() instead of !getElementName(i).empty().
Just in case users write '_:' for call argument.
* Don't suggest argument labels for implicit call expression. For
instance, string interpolation segments.
* For methods, un-curry function interface type so we can get declared
return type.
* For closures, fall back to getting explicit result type in case we
cannot retrieve it from the type of closure itself.
Use ExtensionDecl::getExtendedNominal() to wire up extensions to their
nominal types early in type checking (the bindExtensions()) operation,
rather than going through type validation to do so.
ClassDecl::getSuperclass() produces a complete interface type describing the
superclass of a class, including any generic arguments (for a generic type).
Most callers only need the referenced ClassDecl, which is (now) cheaper
to compute: switch those callers over to ClassDecl::getSuperclassDecl().
Fixes an existing test for SR-5993.
Other instances of fb9c65e. Consistently use
PrintOption.PrintOptionalAsImplicitlyUnwrapped to print IUO.
rdar://problem/41046225
rdar://problem/42443512
Follow-up to f577578a6a. The same
treatment for ternary expression (IfExpr). Plus, fix a regression
introduced in f577578a where infix operators were disappeard from
results.
foldSequence() may hoist these expression up by mutating their sub
expression. When completing operators, this behavior ruins reusability
of operand. Since these expression doesn't affect completion, we can
strip them out.
rdar://problem/42452085
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
Now, an AbstractFunctionDecl always stores a single parameter list.
Furthermore, ConstructorDecl and DestructorDecl always store a
ParamDecl for 'self'.
FuncDecl only has a 'self' if it is a member of a nominal type or
extension, so we tail-allocate the storage for it.
At some point we stopped completing keywords after `else` in an if
statement. Bring back the completion of `if`, which is the only valid
continuation other than a brace.
rdar://37467474
Completing signature depends on its GenericEnvironment which is set
during typechecking. Previously, completing signature using generic type
used to cause assertion failure. e.g.
extension Collection {
subscript(some index: Int) -> Iterator.<COMPLETE HERE>
rdar://problem/41227754
In getOperatorCompletions(), for each every known operators, temporary
expressions are created and typechecked. In this process, typechecker
may set the type of the parsed expression. That may cause non-accurate
completion results or crash at worst.
rdar://problem/28188259
