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.
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.
