This allows building without dispatch and Foundation build roots, which
allows for a multi-phase build. This is intended to support the Windows
staged build where dispatch and Foundation are part of the SDK and
SourceKit-LSP is part of the devtools.
By default, print 1-based line/column numbers using the defacto standard
line:column format. In debug print, continue to use the 0-based values
to match the constructor.
While fallback arguments are being used (either from the fallback build system or fallback settings from the primary build system), withhold semantic diagnostics from sourcekitd and all diagnostics from clangd. This helps prevent user confusion from spurious errors.
- Also remove the DocumentURI standardization in favor of proper equality + hash checks to work around the %40 --> @ encoding issue seen on CI.
* Send `didSave` notifications to clangd if it supports it
- Minor update to the LSP protocol for `didSave` and `colorProvider` to be more in line with the spec
- Only send color requests over to clangd if it supports it
Rationale for this change: clangd recently implemented didSave support,
it is used to rebuild preambles when the user edits a header file
referenced by an open file.
Change-Id: Ie6e2198bdeccb9d1b4083806c254475baadc2d2b
Remove `settings(for:)` from the BuildSystem API in favor of the change callback
- With the `settings(for:)` method removed, we instead block on a
callback from the `BuildSystemManager` which itself handles
the primary build system callback in conjunction with the fallback
system
- We queue up notifications / requests that reference documents
until we receive the callback.
- Remove language from FileBuildSettings as it is no longer needed,
Swift-specific working dir fixes are now in SwiftCompileCommand
- registerForChangeNotifications should inform its delegate
asynchronously instead of immediately
* Support for clangd's go-to-definition for header files
- By forwarding the request to clangd when it fails to give
symbol information, we are able to use its built in
go-to-definition support for headers (jump to header file)
* Add static tibs test for clangd go-to-#include
* Move #include test to SourceKitTests and regenerate linux main
* Fix improper escaping of %40 in file URLs
* Add URL escaping test
* Another attempt to fix broken BuildServerBuildSystemTests test on Linux
- URL's `standardizedFileURL` removes trailing slashes from file URLs,
but only on Linux
- Otherwise can lead to confusing duplicated diagnostics in VSCode
due to its usage of virtual documents for source control diffbases
- sourcekitd does not properly handle virtual files when the
`-working-directory` flag is passed
Change-Id: I9b7f435aac3f7c19082dd6c2fd7561c524356352
- Add support for recently upstreamed `forceRebuild` extension (6ff0228c6d).
Note that until it is merged into Apple-clangd we can't add a test for it with missing headers
- Add a test for the clangd functionality by modifying a generated header file
Change-Id: If53fd88da92e4fc7d9c22af7430300fb3fc0f5ce
The client guarantees that unsupported kinds will be handled, and in
practice some clients, such as Sublime's LSP plugin, use
`"codeActionKind":{"valueSet":[]}`, since they support all kinds anyway.
This behaviour was also clarified in a [spec issue
report](https://github.com/Microsoft/language-server-protocol/issues/620)
where it was confirmed the server can send any actions it wants. It
seems preferable to ignore it.
Request types should always have the suffix Request and notifications
should end with Notification.
Also moved all request and notification types into separate folders to
reduce the number of files in the LanguageServerProtocol folder.
The LSP spec requires us to omit keys for nil values rather than using
the JSON `null` constant in most places. This change to CustomCodable
allows us to do it automatically using CustomCodable, removing one of
the limitations of the property wrapper.
The idea for the adding overloads of `encode` and `decode` came from
https://forums.swift.org/t/pre-pitch-codable-customization-using-propertywrappers/30244/
URL can in fact store URIs, it just doesn't have a very nice API to
interact with them. As long as we only operate on absoluteString, we
should be fine though. So instead of implementing the logic for
detecting file URLs ourselves, we can just use a URL as storage for
DocumentURI.
