`CompilationDatabaseTests` have been flakey on Windows since
https://github.com/swiftlang/sourcekit-lsp/pull/2334. This didn't really
introduce the failure though - it just added tests that now catch it.
The underlying cause is that `filename.isAbsolutePath` sometimes returns
`true` for a relative path, which then causes the CWD to be prepended
instead of the given `compileCommandsDirectory`.
`PathIsRelativeW` requires a null terminated string, so presumably we
were hitting junk after the initial path that sometimes turned it into
an absolute path. From the Windows docs:
> A pointer to a null-terminated string of maximum length MAX_PATH that
contains the path to search.
Fixes#2360
Resolves rdar://165006835
- I think there are valid calls with mixing inline and trailing closures (notably `Debouncer`), so I’m considering whether we should disable that rule.
- The `forEach` rule is a little annoying because we have `forEach` on `SKDResponseArray`. But it caught two cases of using `forEach` on arrays, so I think it’s worth keeping.
The term *build system* predated our wide-spread adoption of BSP for communicating between SourceKit-LSP to the build system and was never really the correct term anyway – ie. a `JSONCompilationDatabaseBuildSystem` never really sounded right. We now have a correct term for the communication layer between SourceKit-LSP: A build server. Rename most occurrences of *build system* to *build server* to reflect this. There are unfortunately a couple lingering instances of *build system* that we can’t change, most notably: `fallbackBuildSystem` in the config file, the `workspace/waitForBuildSystemUpdates` BSP extension request and the `synchronize-for-build-system-updates` experimental feature.