This avoids us using reserved identifiers as the enum case names of all
our underscored protocols like _ObjectiveCBridgeable. I used the
convention PROTOCOL_WITH_NAME to mirror how the known identifiers work.
Swift SVN r32924
Go beyond the existing keyword completions to include more literal
suggestions: 0, 0.0, "text", [item], [key: value], (item, item)
For rdar://problem/21923069
Swift SVN r32890
This mostly works the same as for functions. It required a slight tweak
to how we handle 'var <complete>' to avoid consuming the code completion
token prematurely.
rdar://problem/21012767
Swift SVN r32844
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
