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.
State the previously unstated nested type requirement that CodingKeys adds to the witness requirements of a given type. The goal is to make this member cheap to synthesize, and independent of the expensive protocol conformance checks required to append it to the member list.
Further, this makes a clean conceptual separation between what I'm calling "nested type requirements" and actual type and value requirements.
With luck, we'll never have to use this attribute anywhere else.
Now that CMAKE_HOST_SYSTEM_NAME and CMAKE_SYSTEM_NAME are set by default to
Android in the Termux app, make the needed tweaks. Some tests were adapted
to work natively on Android too, adds sys/cdefs.h to the Bionic modulemap,
and includes the start of native Android platform support in the build-script.
SwiftSourceInfo files provide source location information for decls coming from
loaded modules. For most IDE use cases it either has an undesirable impact on
performance with no benefit (code completion), results in stale locations being
used instead of more up-to-date indexer locations (cursor info), or has no
observable effect (live diagnostics, which are filtered to just those with a
location in the primary file).
For non-IDE clients of SourceKit though, cursor info providing declaration
locations for symbols from other modules is useful, so add a global
configuration option (and a new request to set it) to control whether
.swiftsourceinfo files are loaded or not based on use case (they are loaded by
default).
Using \0 as a representation of the cursor position is a implementation
detail and is done by SourceKit. Client including complete-test should
not do it.
This inserted test used to be treated as EOF in compiler so the code
after the completion position is completely ignored.
Restore the previous commit which somehow passed the buildbot given a
missing condition on the sub-configure for libdispatch. This makes it
more explicit as to what the desire is; the variable was being used to
serve as a proxy for whether the build is not on a Darwin target.
This flag was being used as an alias for whether or not the host is
non-Darwin. Rather than adding custom checks for this, use the explicit
check that CMake supports. This simplifies the logic and avoids the
proliferation of custom variables which can become confusing for others
who are not familiar with the custom build infrastructure.
