- 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.
Having `BuildSettingsLogger` can be problematic if we launch multple `SourceKitLSPServer` instances in the same process (such as during testing). In that case it could happen that a previous `SourceKitLSPServer` instance logs build settings and then the second instance doesn’t log its build settings (if they are the same) because the shared logger has already logged them.
This issue is resolved by scoping `BuildSettingsLogger` to the lifetime of `BuildServerManager` (ie. one per workspace).
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.