`_WIN32` indicates if we are targeting Windows or not. Directly use that macro
rather than `LLVM_ON_WIN32` used by LLVM. This makes it easier to port the
code.
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
`WIN32_LEAN_AND_MEAN` prevents "rarely-used" headers from being pulled in. This
significantly reduced preprocessor pressure, speeding up compile. It also
reduces the amount of cruft pulled in by the Windows.h.
`NOMINMAX` ensures that the `min` and `max` macros are not defined. These
macros collide with the use of `min` and `max` from C++ in certain cases: e.g.
`std::limits<T>`.
SVN r272232 added an additional parameter to PrintStackTraceOnError. Update the
use of the API to add the executable name. We can assume that argv[0] will
always be provided as that is the name of the binary itself.
When building SourceKit on Linux, sourcekitdAPI would not be linked to
SourceKitSwiftLang, which caused the following symbols to be undefined:
- `SourceKit::LangSupport::SynthesizedUSRSeparator`
- `SourceKit::LangSupport::createSwiftLangSupport(SourceKit::Context&)`
Link SourceKitSwiftLang to resolve these symbols.
Most SourceKit build products are linked against either
sourcekitd (which uses XPC) or sourcekitdInProc (which
does not) based on the `SWIFT_SOURCEKIT_USE_INPROC_LIBRARY`
CMake option. Adapt `sourcekitd-repl` to fit this established
pattern.
SourceKit makes heavy use of blocks. In order to port SourceKit to Linux,
we either need to rewrite much of it to use function pointers, or we must
require a blocks runtime. This commit requires a blocks runtime, but only
when SourceKit is being built. Currently, SourceKit is not built on Linux,
so this should not affect anyone.
... 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
`ThreadSafeRefCntPtr.h` references `std::enable_if` and `std::move`,
but does not include `<type_traits>` or `<utility>`. This results
errors when compiling on Linux.
LLVM's CMake modules include a function `llvm_process_sources()`,
which (among other things) verifies that all source files in a
directory are either included in the list of source files to process,
or are included in a list `LLVM_OPTIONAL_SOURCES`.
SourceKit's CMake functions make use of this LLVM function, but do
not register any files as "optional". When attempting to configure
CMake to include SourceKit on a Linux host machine, source files
that are only included on Darwin host machines cause this function
to raise an error.
Mark Darwin-only SourceKit files as "optional" to avoid the error.
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
`sourcekitd-test` does not use LLVM's command line parsing utilities at
all, except to print a help message. However, the help message is
misleading: by default `llvm::cl` explains the `-help`, `-help-hidden`,
and `-version` options are available, but `sourcekitd-test` does not support
any of those.
https://bugs.swift.org/browse/SR-1421 tracks improving
`sourcekitd-test` help output, which will most likely involve migrating
it to LLVM's command line library. In the meantime, remove the
misleading "help" message.
Also, it should be noted that the return value of `1` returned after
printing the help message is not actually translated into a non-zero
exit code for the program. Add a "FIXME" to track the issue for now.
- Convert `Protocol.txt` to `Protocol.md`, and use valid Markdown
syntax.
- Spruce up the documentation in the "code completion": more details on
how to test via the REPL, clearer sentences, etc.
- Fix an error in which `sourcekitd-test -req=complete -offset=<offset>`
used the incorrect option `-cc-offset`.
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.
