Otherwise we can get a situation where a `.swift` file is removed from swift-syntax, its `.o` file is still in the build directory because the build folder wasn't cleaned and thus we would link against the stale `.o` file.
rdar://142666044
It is important that we cache this because we might find a lot of symbols in the same container for eg. workspace symbols (eg. consider many symbols in the same C++ namespace). If we didn't cache this value, then we would need to perform a `primaryDefinitionOrDeclarationOccurrence` lookup for all of these containers, which is expensive.
For example, searching for `only` in SourceKit-LSP’s codebase used to not return results in more than 20s (after which I gave up) and now returns >8000 results in <2s.
rdar://141412138
`inProgressTextDocumentRequests` is supposed to only be accessed on `textDocumentTrackingQueue` but we were accessing it outside of that queue. Because of this, we might try to remove requests from `inProgressTextDocumentRequests` before adding them, which would cause them to stay in the list indefinitely.
For reasons that are completely oblivious to me, `DispatchIO.write`, which is used to write LSP responses to stdout fails with error code 5 on Windows unless we call `AbsolutePath(validating:)` on some URL first.
`SourceFilesAndDirectoriesKey` contained all source files in the project and computing its hash value was pretty expensive. The key didn’t really provide any value here because the only way it changes is if the build targets change and if that’s the case, we already clear `cachedSourceFilesAndDirectories`, so we can just avoid the hash value computation.
VS Code spells file paths with a lowercase drive letter, while the rest of Windows APIs use an uppercase drive letter. Normalize the drive letter spelling to be uppercase.
Fixes#1855
rdar://141001203
Currently, when there‘s a syntax error in a package manifest, we don’t get any build settings from it in SourceKit-LSP and thus loose almost all semantic functionality. If we can’t parse the package manifest, fall back to providing build settings by assuming it has the current Swift tools version.
Currently, when there‘s a syntax error in a package manifest, we don’t get any build settings from it in SourceKit-LSP and thus loose almost all semantic functionality. If we can’t parse the package manifest, fall back to providing build settings by assuming it has the current Swift tools version.
Fixes#1704
rdar://136423767
Consider the following scenario: A project has target A containing A.swift an target B containing B.swift. B.swift is a symlink to A.swift. When A.swift is modified, both the dependencies of A and B need to be marked as having an out-of-date preparation status, not just A.
