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
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
We require some level of consistency between the way the overlays were
built and what we work with in our mock SDK. The IDE/sdk_sugar.swift
test failure was because the overlay referenced "init(coder:)" while
the test was looking for "init(withCoder:)". Hilarity ensued
<rdar://problem/17791048>.
This only impacts testing.
Swift SVN r20564
We want to complete foo(p: (Int, Int)) as foo({#(p): (Int, Int)#}), not
as foo({#Int#}, {#Int#}). Also, make initializers go through the
function parameter code path rather than the enum one, since we don't
want to recursively find parameters in tuples.
<rdar://problem/17461862>
Swift SVN r19514
The leading paren is included for display purposes only, not inserted
in the code if already present. It makes the displayed text in the
code completion list symmetrical with respect to open/close parens.
Add markups when printing annotation chunks so it becomes testable.
Update tests accordingly, and include tests for leading parens.
This addresses <rdar://problem/16918310>.
Swift SVN r18126
