This adds an implicit body so that we can dig out the return type
context the same way as a normal function. For now, we are also treating
the first expression in a multi-statement implicit getter body the same
way; we'll need to refactor how we complete in accessors to
differentiate those cases.
When completing in the only expression of closure, use the return type
of the closure as the type context for the code-completion. However,
since code-completion may be on an incomplete input, we only use the
return type to improve the quality of the result, not to mark it
invalid, since (a) we may add another statement afterwards, or (b) if
the context type is Void it doesn't need to match the value.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
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
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.
* Consolidate CompletionKind::KeyPathExpr and CompletionKind::KeyPathExprDot
to CompletionKind::KeyPathExprObjC
* Make completeKeyPath() to receive DotLoc.
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
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
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
Complete generic parameters and their members inside generic where
clauses on structs, classes, enums, extensions, typealiases, funcs,
subscripts and inits.
Still not handled correctly are associatedtypes.
rdar://problem/20582394
For normal completions it behaves the same as PostfixExprBeginning, but
it provides a hook for clients to provide a custom completion for this
position. For example, you might want to a x ..< y snippet in this
position.
rdar://problem/29910383
Implement code completion support for Objective-C #keyPath
expressions, using semantic analysis of the partially-typed keypath
argument to provide an appropriate set of results (i.e., just
properties and types).
This implements all of the necessary parts of SE-0062 / SR-1237 /
rdar://problem/25710611, although at some point I'd like to follow it
up with some warnings to help migrate existing string literals to
Implement basic code completion support for #selector with property
getters/setters. The vast majority of this implementation comes from
Alex Hoppen (@ahoppen), with only a handful of my own tweaks. Alex has
more interesting ideas on improving this that I wasn't quite ready to
commit to, so this is more basic than the overall goal.
When we're code completing a postfix or dot expression inside the
subexpression of an #selector expression, prefer compound function
names. This helps us write, e.g.,
#selector(UIView.
and get completions such as "insertSubview(_:aboveSubview:)". Fixes
rdar://problem/24470075.
Correct format:
```
//===--- Name of file - Description ----------------------------*- Lang -*-===//
```
Notes:
* Comment line should be exactly 80 chars.
* Padding: Pad with dashes after "Description" to reach 80 chars.
* "Name of file", "Description" and "Lang" are all optional.
* In case of missing "Lang": drop the "-*-" markers.
* In case of missing space: drop one, two or three dashes before "Name of file".
Now we can handle simple cases like
1 + 1 == 2 <here>
and correctly suggest both + on the 2 and || on the boolean. When the
LHS doesn't type-check we fallback to using only the operand immediately
to the left.
Swift SVN r32489
When users invoke code completion at an argument position, we suggest argument names,
if required however not specified, or a list of argument values. These values are annotated
with their type relation to the expected argument types, so that
Xcode can prioritize those values that apply over those that do not.
This also fixes: rdar://21727063
Swift SVN r31505
When users complete the right-hand side of an assignment expression, we only
show the results whose types are convertible to those of the left-hand side.
Swift SVN r31357
