Since Musl is sufficiently different from Glibc (see https://wiki.musl-libc.org/functional-differences-from-glibc.html), it requires a different import, which now should be applied to files that have `import Glibc` in them.
Musl is a low footprint libc that's used in Linux distributions such as Alpine Linux, which allows producing fairly small container images. Additionally, unlike Glibc, musl allows full static linking, meaning apps can be easily distributed to an arbitrary Linux distribution that may have a version of Glibc incompatible with the one that Swift is usually built with or no Glibc installed at all.
We weren’t semantically highlighting references to actors because we missed the `ref_actor` case from the sourcekitd `annotations` response.
Fixes#694
rdar://104573568
SKSupport now requires a link against Foundation, update the build
system to track that dependency.
Co-authored-by: Max Desiatov <m_desiatov@apple.com>
The dependency on `TSCUtility` was strictly for identifying the platform
of execution. This logic is relatively self-contained and effectively an
extension over an enumeration. Replicate this logic with updates for new
syntactic improvements. This allows us to partially reduce dependency on
swift-tools-support-core. The dependency on TSCBasic is more complicated
to remove due to the extensive use of `AbsolutePath`.
Co-authored-by: Alex Hoppen <alex@alexhoppen.de>
Explicitly import interfaces from TSCBasic which now allows us to
identify all the swift-tools-support-core interfaces which are in
use in SourceKit-LSP.
Replace the use of the deprecated `Lock` from swift-tools-support-core
with `NSLock`. The benefit of the deprecated interface was the
`withLock` function which is easily replicated and very unlikely to
change. By doing so we avoid the warnings about `Lock` being deprecated
when building SourceKit-LSP.
This adjusts the sourcekit-lsp build to use static linking for the
internal libraries. It is not currently possible to build
SourceKitLSP.dll as that requires re-exporting the interfaces from the
consumed modules. However, this allows us to reduce the overall size of
the distribution of SourceKit-LSP by ~1 MiB and reduces the
distributed file set. The values here assume partial static linking of
swift-package-manager, which helps reduce the total size.
Before:
228,352 BuildServerProtocol.dll
1,773,056 LanguageServerProtocol.dll
114,688 LanguageServerProtocolJSONRPC.dll
49,152 LSPLogging.dll
262,656 SKCore.dll
54,784 SKSupport.dll
80,896 SKSwiftPMWorkspace.dll
150,528 SourceKitD.dll
645,632 SourceKitLSP.dll
70,144 sourcekit-lsp.exe
3,429,888 bytes
After:
2,416,640 sourcekit-lsp.exe
2,416,640 bytes
The swift project uses a minimum of CMake 3.19.6, and the current CMake
release is 3.22. Update the CMake requirement to a newer version and
remove the workaround for older releases of CMake.
This is an implementation of LSP's semantic tokens for Swift. Both
lexical and semantic tokens are provided by using the syntaxmap and the
semantic annotations provided as part of SourceKit's open responses and
document update notifications.
While lexical tokens are parsed and stored in the DocumentManager
synchronously, semantic tokens are provided asynchronously. If an edit
occurs, tokens are automatically shifted by the DocumentManager. This is
especially relevant for lexical tokens, which are updated in deltas.
In addition, unit tests are added that assert that both lexical and
semantic tokens are provided and shifted correctly upon edits.
- Add UID for CollectExpressionType request
- Add ExpressionTypeInfo structure
- Add keys to support sourcekitd's CollectExpressionType
- Implement CollectExpressionType request
- Add SwiftLanguageServer.expressionTypeInfos
- Add InlayHint and supporting types
- Add InlayHintsRequest
- Add inlayHints handler stub
- Implement inlay hints request
- Update InlayHint to follow the current proposal
- # This is the commit message #11:
- ...as described in the LSP proposal
- Update doc comment on InlayHintsRequest
- Map inlay hints lazily
- Fix minor style issue
- Add new files to CMakeLists.txt
- Specify commit of the current inlay hints proposal state
- Add public, memberwise initializer for InlayHintsRequest
- assert(false) if deserializing ExpressionTypeInfos fails
- Add dispatch precondition to _expressionTypeInfos
- Add InlayHintsRequest to the builtinRequests
- Factor out function for querying document symbols for URI
- Only render inlay hints after variable bindings
- Test inlay hints on empty document
- Test inlay hints for some simple bindings
- Test ranged inlay hint requests
- Make sure that inlay hints are unique per position
- Test inlay hints for fields
- Apply various PR suggestions regarding inlay hints
- Update inlay hint tests and add case with explicit type annotations
- Continue iterating if an ExpressionTypeInfo fails to deserialize
- Don't log entire LSP notifications/requests for the `info` level, instead log of the form:
- `Notification<method>` e.g. Notification<textDocument/publishDiagnostics>
- `Request<method(id)>` e.g. Request<textDocument/hover(6)>
- `Response<method(id)` e.g. Response<textDocument/hover(6)>
- Only log sourcekitd requests/responses at the debug level
* The interesting keys to split out are "code-completion options", not
any key that is used by completion.
* Sort the main key list
* Fix the name of the doc_brief key
For now, we only have one concrete implementation in sourcekit-lsp
itself, but it is useful for libraries to be able to wrap their own
sourcekitd implementation for example if they have an existing external
use of sourcekitd in C code.
The notification handler and initialize/shutdown APIs all modify global
state within the service, so handle them inside the wrapper to prevent
accidental misuse. Also add support for multiplexing the notification
handler, since it can be useful to have multiple handlers, especially
for global notifications.
