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.
`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.
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.
`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.
Fold UnitTest into the subkind, now that it's a bitself, and then remove
the unnecessary inheritance for IndexSymbol and its SourceKit indexing
equivalent.
Add a dependency on LLVMCore to satisfy the link dependency. Upstream changes
to the Target structure have caused a missing definition:
Undefined symbols for architecture ...:
"llvm::DataLayout::~DataLayout()", referenced from:
clang::TargetInfo::~TargetInfo() in libclangBasic.a(TargetInfo.cpp.o)
Instead of using 'key.usr' and 'key.synthesizedusr', we start to use 'key.usr' and 'key.original-usr' so
that 'key.usr' is consistently being the unique ID for a code entity.
This eventually calls the code from ReconstructType to try to find the
Decl for a USR. For now, only works in a file, not a generated
interface.
rdar://problem/25017817
The guts of the callback are the interesting part that we want to share
between offset-based and usr-based cursor info. Pull the code that
actually finds the cursor info up into the caller.
No need to call sourcekitd::shutdown() since the process is going down
anyway, plus if we get a new connection before the process closes then
we will fail to re-initialize properly since the initialize call is at main.
Also expose the printing function as a SwiftLangSupport static method.
Ideally we could move this into libIDE, but it currently depends on the
UIdent visitor to get decl-specific tag names and it's not obvious how
we should hoist/abstract that out in a nice way.
rdar://problem/24292226
rdar://problem/24292304
