This library is already supplied by the LLVM CMake config, so adding it here
sometimes causes the CommandLine option parser to fail, as it registers the
same option twice.
This should repair the Windows build after #29451. The quoting
behaviour was incorrect and was constructing an invalid compiler
invocation. Solve the issue by using `target_include_directories`
instead. However, since this needs the target, hoist the flag
computation to the local sites. This replicates more logic because of
the custom build trying to replicate the CMake build logic in CMake.
Use specific operations for setting the compile flags, link flags,
linked libraries, and library search paths. This allows us to use CMake
more effectively, simplifies the logic, and will ensure that flags are
not duplicated.
When doing header interface generation, we interpret clang command-line
arguments in `initInvocationByClangArguments` and attempt to setup a
matching Swift compiler invocation. One important argument is the module
cache, but clang will only interpret `-fmodules-cache-path` if modules
are enabled (typically with `-fmodules`). While the header itself might
not need modules, Swift will import its own shims module and during
testing this needs to honour lit's provided cache. So we add -fmodules
in sourcekitd-test anytime we add -fmodules-cache-path.
rdar://58836540
This moves the handling of the RPATH and the exported symbol to the
binary themselves. The exported symbol is needed due to the use of the
exported symbol list. This makes the small difference that `_main` is
always exported on Darwin which is not strictly needed in ASAN as ASAN
provides the entry point.
The RPATH is only setup on installation which is sufficient for testing
purposes as CMake ensures that the libraries are fully linked and will
be loaded properly when run from the build tree.
Add a global -module-cache-path option to `sourcekitd-test` and
`complete-test` and have lit provide the default module cache in its
substitutions. Previously many tests have explicitly provided the
`%mcp_opt` option, but this is easy to forget when writing new tests.
The module cache is inserted into the compiler arguments at the
beginning so that it's still possible for a test to override it with a
per-test cache if desired.
rdar://58752842
Add a platform kind and availability attributes for macCatalyst. macCatalyst
uses iOS version numbers and inherits availability from iOS attributes unless
a macCatalyst attribute is explicitly provided.
in all SourceKit requests.
This validation may call many stat(2). Since we don't expect system files
are edited. Disable it for SourceKit requests. Even if they are edited,
manual builds can validates and updates them.
rdar://problem/58550697
Some versions of libedit may have histedit.h but not the Unicode
functions. Explicitly check for the Unicode functions in the found
libedit to ensure the check is accurate.
I considered making this a component of the LibEdit package in our find
module, but CMake's documentation [1] says "Packages that find multiple
semi-independent parts (like bundles of libraries) should search for the
components...", and the "multiple semi-independent parts" definitely
isn't the case here; we're just interested in determining if the found
library supports a particular feature.
[1] https://cmake.org/cmake/help/v3.16/manual/cmake-developer.7.html#find-modules
The current FOUND_VAR for FindLibEdit is libedit_FOUND but wasn't set by
find_package_handle_standard_args. However this isn't valid for the
package name.
The argument for FOUND_VAR is "libedit_FOUND", but only
"LibEdit_FOUND" and "LIBEDIT_FOUND" are valid names.
This fixes all the variables set by FindLibEdit to match the desired
naming scheme.
Thanks to Jonas for fixing the variable names!
Use the FindLibEdit.cmake module from LLDB to properly control where
the libedit libraries are searched for and linked from as well as where
the headers come from. This uses the standard mechanisms which allows
users to control where libedit is pulled from (which is important for
cross-compilation).
This second version is more aggressive about pruning the libedit
handling. The Ubuntu 14.04 version of libedit does not have
`histedit.h`, and the intent is to rely on that to determine if we have
unicode support or not.
To controls the lifetime of CompilerInstance within CompletionIntance.
- Prevent from using the same CompilerInstance from multiple completion
requests
- Separate the stacktrace between "fast" and "normal" completions
- Further code consolidation between various completion-like requests
- Introduce ide::CompletionInstance to manage CompilerInstance
- `CompletionInstance` vends the cached CompilerInstance when:
-- The compiler arguments (i.e. CompilerInvocation) has has not changed
-- The primary file is the same
-- The completion happens inside function bodies in both previous and
current completion
-- The interface hash of the primary file has not changed
- Otherwise, it vends a fresh CompilerInstance and cache it for the next
completion
rdar://problem/20787086
I think this was just an oversight. The new cmake 3.16 seems to choke if we do
not add SourceKit to the exports file since there are dependencies upon it in
other swift libraries.
codeCompleteOpen() has own sorting algorithm, codeComplete() calls this
sortCompletionResults() in its callback. So this pre-sorting is
completely unnecessary.
