This crashed until recently, and although I couldn't find a case where
the RHS had a null type anymore, I also couldn't see a reason it
couldn't happen, since we don't always assign types to every expression
in code-completion type-checking.
rdar://problem/23111219
Swift SVN r32793
When not completing a full call pattern for the first argument, such as
here:
foo(<here>, arg2: blah)
we now show the argument label if appropriate.
For rdar://problem/22804670
Swift SVN r32774
Peek at the token following the code completion location to decide
whether or not to provide completions for entire call patterns. When
the next token looks like it's part of an existing call we don't show
the patterns because they will "push out" the existing arguments.
We should now get:
Foo<here> => (blah, blah)
Foo(<here> => ['(']blah, blah)
Foo(<here>) => ['(']blah, blah[')']
Foo(<here>, blah) => just complete the values for arg1**
Foo(<here>blah, blah) => just complete the values for arg1
** A further improvement will be to add the argument label completion
for the first argument (if applicable) when we aren't showing a full
call pattern.
rdar://problem/22804670
Swift SVN r32765
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
...into separate prefix, postfix and infix operators. Also incidentally
make the whitespace around operators special so we can decide when to
skip over it. Tested in SourceKit.
Swift SVN r32468
This allows us to start code-completing infix operators in postfix
expressions. As a first step, this patch only handles completing
against the immediate LHS (so for example 1 == 1 <here> doesn't suggest
boolean operators yet).
The next step is to feed the leading sequence expression from the parser
in so we can consider how the operator being completed fits into the
whole sequence expression.
For rdar://problem/22460167
Swift SVN r32465
This allows us to start code-completing postfix operators (generally !,
++, and --), which lays some of the groundwork for completing the much
more interesting infix operators.
These only show up when in postfix position
x<here>
For rdar://problem/22460167
Swift SVN r32355
For now, just avoid adding the completion since that will assert later
when we try to sort. In the future we could actually complete something
useful here, since we can dig out the names of the parameters even if
the type is invalid.
rdar://problem/22834017
Swift SVN r32211
When completing at the sequence position of for each statment (for i in <HRER> {}),
values of sequence type should have higher priority than the rest.
Swift SVN r32202
Global variables from the same source file are more like locals when
writing top-level code, particularly in Playgrounds. Other declarations
(types, global functions, etc.) are unaffected.
rdar://problem/22329905
Swift SVN r31992
We can't afford to walk all the top-level results, which includes every
type and global function in the SDK. Instead, use the usual caching
mechanisms.
This means we never get type relations on top-level SDK symbols, but
this should be fine for most cases because:
1) For ObjC code, we don't generally care about global functions. And
in practice most of the matching global functions for common types are
not high-priority anyway (e.g. alignof for Int).
2) In a previous commit I manually added the names of types so that we
can do later code completions to get initializers and static methods.
E.g. you will still get "CGRect" if you complete inside drawInRect(...).
Top-level results from the current module should be unaffected.
Swift SVN r31961
Since other module results are cache, manually add the type names of
expected nominal types in call arguments so that we can get the type
relationship correct
For rdar://problem/22271094
Swift SVN r31959
This exposes the code completion kind so that SourceKit has more
information about the code completion context.
For rdar://problem/22460026
Swift SVN r31925
By analyzing the context of a member access expression, we can prioritize the member
completion results by the expected type. As the initial step, we support call arguments
as context.
Swift SVN r31837
When completing type members, teach the code completion engine to
transform the archetypes appearing in code completion results to the
actual types. NFC
Swift SVN r31628
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
The conformance lookup table is responsible for answering queries
about the protocols to which a particular nominal type conforms, so
stop storing (redundant and incorrect) protocol lists on the ASTs for
nominal types. Protocol types still store the list of protocols that
they inherit, however.
As a drive-by, stop lying about the number of bits that ProtocolDecl
uses on top of NominalTypeDecl, and move the overflow bits down into
ProtocolDecl itself so we don't bloat Decl unnecessarily.
Swift SVN r31381
We use an enum to describe the relationship between a code completion result
and the expected type at the code completion site. We can use this relationship
to prioritize candidates on the SourceKit side.
Swift SVN r31371
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
