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
For more context, see:
1. https://github.com/apple/swift/pull/29239 - original PR which introduced
the change, including an LLDB-side change.
2. The immediately preceding commit, which reverted this change.
3. https://github.com/apple/swift/pull/29350 which revealed some breakage
caused by the changes in PR 29239 (unrelated to printing).
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
This was being done at an odd point in the frontend presumably because by that point the private discriminator had been fully computed. Instead, push the conditions for generating the prefix data down to debug info generation and stop mutating IRGenOptions::DebugFlag in the frontend.
Motivation: `GenericSignatureImpl::getCanonicalSignature` crashes for
`GenericSignature` with underlying `nullptr`. This led to verbose workarounds
when computing `CanGenericSignature` from `GenericSignature`.
Solution: `GenericSignature::getCanonicalSignature` is a wrapper around
`GenericSignatureImpl::getCanonicalSignature` that returns the canonical
signature, or `nullptr` if the underlying pointer is `nullptr`.
Rewrite all verbose workarounds using `GenericSignature::getCanonicalSignature`.
Adds a tool `swift-symbolgraph-extract` that reads an existing Swift
module and prints a platform- and language-agnostic JSON description of
the module, primarly for documentation.
Adds a small sub-library `SymbolGraphGen` which houses the core
implementation for collecting relevant information about declarations.
The main entry point is integrated directly into the driver as a mode:
the tool is meant to be run outside of the normal edit-compile-run/test
workflow to avoid impacting build times.
Along with common options for other tools, unique options include
`pretty-print` for debugging, and a `minimum-access-level` options for
including internal documentation.
A symbol graph is a directed graph where the nodes are symbols in a
module and the edges are relationships between them. For example, a
`struct S` may have a member `var x`. The graph would have two nodes for
`S` and `x`, and one "member-of" relationship edge. Other relationship
kinds include "inherits-from" or "conforms to". The data format for a
symbol graph is still under development and may change without notice
until a specificiation and versioning scheme is published.
Various aspects about a symbol are recorded in the nodes, such as
availability, documentation comments, or data needed for printing the
shapes of declarations without having to understand specifics about the
langauge.
Implicit and public-underscored stdlib declarations are not included by
default.
rdar://problem/55346798
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
This change ensures using .swiftmodule built from source has the same behavior as
using .swiftmodule built from .swiftinterface.
A swift-ide-test utility is added to print linked libraries from a Swift module for
testing purposes.
rdar://58057556
SourceKit doesn't set up a compiler instance, just a parser, for its syntactic
requests (document structure and syntax coloring). This updates swift-ide-test
to minic this setup to ensure the StructureAnnotator/PrintSyntaxColorWalker and
underlying SyntaxModelWalker handle this setup (which has no type-checker
installed) for all our swift-ide-test based tests.
Resolves rdar://problem/57202584
Because we won’t be serializing this attribute, add custom diagnostics for the cases where:
- We add @_hasMissingDesignatedInits to an open class, which means subclasses won’t be able to inherit its inits
- We remove @_inheritsConvenienceInitializers, which means APIs are removed
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.
The annotation must precede the declaration to which it appertains
during the definition. The re-ordering was silently accepted by clang
but is not correct as per the GNU style. This was flagged by GCC 7.
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).
