SourceKit invariantly expands the last argument in a function call as trailing closure,
if it is of function type. However, there are situations when inline closures
are preferred; for example, when the last argument is not the only closure in the function
call. This patch modifies SourceKit so that when the argument contains multiple closures,
the last argument is expanded as inline closure.
Showing only the conforming associated types provides
little information to doc viewers. This patch digs the
underlying type of an associated type to report the
conformance info of those.
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
Setting this value is equivalent to setting:
include_directories(${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR})
in all subdirectories. Since these are all macros, this means that we are adding to the configuration
path the root swift directory. There is no reason to do this and will result in
confusion/bugs in the future.
rdar://26154980
This eliminates us setting an LLVM_ prefixed variable in a situation where there is
a viable alternative.
We want to eliminate as many of these as possible since they can cause conflicts
with variables set in LLVMConfig.cmake.
I also added some convenience tablegen functions in AddSwiftTableGen.cmake and
changed all tblgen users to use that instead.
rdar://26154980
Darwin can use the XPC implementation of this even for the in-proc library
build, this alternative implementation is need for Linux where XPC services
are not available.
This implementation is derived from the existing XPC one but replaces XPC
services' object model with a basic class hierarchy providing
reference-counted objects for the value types and collections that
compose the sourcekitd API's request and response types.
`_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.
