This adds a narrow special case in code-completion for control-flow-like
methods such as DispatchQueue().sync that are () -> (), to add a new
completion where the trailing closure is immediately expanded rather
than having to invoke placeholder expansion as a second step.
rdar://problem/26628804
The index may be at the end of the ArrayRef of chunks if the completion
ends with a simple parameter with no type annotation. Check that the
index is in-bounds before adding text.
rdar://problem/26273906
Surface these results in the codecomplete code path (they're already
there in the codecomplete.open code path) so we can use them from IDEs.
For now, just use ad-hoc filtering to show them when the type matches
(or there is no expected type). Ideally we would make this filtering
configurable like we do in the codecomplete.open code path.
rdar://problem/25836544
... and don't try to filter the extended results. Once the results are
extended with the common prefix they will not match identifier filter
rules, which will create differences between completions depending on
whether they had a filter text or were a postfix expression. Also,
allow filtering by name directly on the inner operator name for inner
operators.
rdar://problem/26312235
Ideally we would have precise completion for all our keywords; for now,
just imporove handling of 'return', which we can do by checking if the
current context is a function/closure/init/subscript/etc.
rdar://problem/26307555
We want inputs for function names to follow SE-0021 with the exception
that a function with no arguments is spelled `foo()` instead of `foo`,
because we have no type to disambiguate with and it's not ambiguous with
a call in this context.
Internally, we use a filter name without underscores because we don't
want to introduce spurious matches to the `_` character which might be
part of identifiers.
For now, continue to accept the old names to ease the transition.
rdar://problem/24350800
The filter name of a function should match the spelling of the function
name according to the language except that we don't insert _ for unnamed
parameters because underscores are legal inside identifiers and we don't
want to introduce spurious matches (also, we keep the () on a
parameterless function for disambiguation).
rdar://problem/26118915
In the new code-completion code path, force any known operators to go
through a fixed sort order. To identify operators unambiguously, add a
new BuiltinOperator code-completion kind to handle non-decl operators
(!, ., ?., and =).
rdar://problem/25994246
rdar://problem/23440367
Fold UnitTest into the subkind, now that it's a bitself, and then remove
the unnecessary inheritance for IndexSymbol and its SourceKit indexing
equivalent.
Eventually we should just have one IndexSymbol, with all the
information. Once we kill FuncDeclIndexSymbol and can get rid of the
enum, we will regain most of the bytes we lost by inlining receiverUSR.
As a first step toward having more detailed "role" information, thread
through a SymbolRole bitset. For now it just contains the existing ref
vs. definition status.
This sort is only for codeComplete, not for codeCompleteOpen, but we
were doing it indiscrimiately leading to ~15% performance penalty in the
latter code path.
rdar://problem/25887631
Having a single interface for source files and modules and having to
pass in a buffer id was a crappy API. This splits the interface to take
either a Module or a SourceFile and handles the buffer id stuff
internally.
The goal is to be able to move the core IndexSwiftASTWalker code out of
SourceKit, leaving only the serialization bits behind.
Mostly this replaces some direct uses of UIdent strings with explicit
enums, and then adds the translation code to produce those enums and to
convert them into UIdents in SourceKit.
rdar://problem/22348041
These results are cached, so we can't use the type-relation. Instead we
use a small hack of checking the textual return type for "Void". This
is obviously not ideal, but it lets us detect the most important cases.
rdar://problem/22810741
As implied in rdar://24818863, striking through a module name may be an overkill to suggest the module is redundant to import. We try to
fine-grain not-recommended-reason so that proper UI cue can be adopted in the future.
