Apply review suggestions

Author: polac24

Sources/XCRemoteCache/Commands/SwiftFrontend/SwiftFrontendOrchestrator.swift

@@ -86,7 +86,7 @@ class CommonSwiftFrontendOrchestrator {
     /// the critical section, the code realizes that remote cache cannot be used
     /// (in practice - a new file has been added)
     /// None of compilation process (so with '-c' args) can continue until the entire emit-module logic finishes
-    /// Because it is expected to happen no that often and emit-module is usually quite fast, this makes the
+    /// Because it is expected to happen not that often and emit-module is usually quite fast, this makes the
     /// implementation way simpler. If we ever want to optimize it, we should release the lock as early
     /// as we know, the remote cache cannot be used. Then all other compilation process (-c) can run
     /// in parallel with emit-module

docs/design/SwiftDriverIntegration.md

@@ -1,35 +1,46 @@
 ## Swift Driver Integration
 
-### Pre Swift Driver Integration 
+### Pre Swift Driver Integration
 
 Historically (prior to Xcode 14), Swift compilation step was invoked by Xcode as a single external process. Xcode was calling `swiftc` and passing all required parameters (like all input files, output destinations, header paths etc.), and reading its standard output to recognize the status/state of a compilation. Essentially, there were two build systems: "the big one" from Xcode and "small one" by Swift.
 
 That design was easy to mock in the XCRemoteCache, where the `xcswiftc` wrapper was first inspecting if the cached artifact can be reused (e.g. no new input `.swift` files were added to the list of compilation files) and based on that either continuing with the local compilation (cache miss) or mocking the compilation and existing early (cache hit).
 
-![Pre Swift Driver Integration](./../img/pre-driver.png)
-
+<p>
+    <img src="docs/img/pre-driver.png#gh-light-mode-only">
+    <img src="docs/img/pre-driver-dark.png#gh-dark-mode-only">
+</p>
 
 ### Swift Driver Integration Design
 
 With the upgraded design (aka Swift Driver Integration), Xcode splits the work into `n` subprocesses (when `n` is ~CPU), each responsible to compile a subset of files/actions. To align with that, XCRemoteCache meeds to specify a single place to identify if the cached artifact is applicable. `swift-frontend` has been picked for that - process responsible for module emitting. By reviewing Xcode's behavior, it has been found that this process is scheduled very early in the workflow timeline (with some approximation, we could say it is scheduled as a first step) so it seems as best candidate for the "pre-work".
 
-As the same executable `swift-frontend` is invoked multiple times for the same target (e.g. to emit module, multiple batches of compilation etc.), XCRemoteCaches uses a file lock-based synchronization. Each `xcswift-frontend` (the wrapper for `swift-frontend`) tries to acquire a unique lock file. The lock has a name `$LLBUILD_BUILD_ID.lock`, which is unique for each build, placed in the `Intermediate` directory. `xcswift-frontend` process reads its content to find if the "pre-work" from the emit-module has already been done - if not, it releases a lock a gives a way to other processes (presumably the "emit-module") to do the required work. As a lock file is unique per target and a build (it is actually unique per target compilation, placed in `TARGET_TEMP_DIR`), initially the file is empty. 
+As the same executable `swift-frontend` is invoked multiple times for the same target (e.g. to emit module, multiple batches of compilation etc.), XCRemoteCaches uses a file lock-based synchronization. Each `xcswift-frontend` (the wrapper for `swift-frontend`) tries to acquire a unique lock file. The lock has a name `$LLBUILD_BUILD_ID.lock`, which is unique for each build, placed in the `Intermediate` directory. `xcswift-frontend` process reads its content to find if the "pre-work" from the emit-module has already been done - if not, it releases a lock a gives a way to other processes (presumably the "emit-module") to do the required work. As a lock file is unique per target and a build (it is actually unique per target compilation, placed in `TARGET_TEMP_DIR`), initially the file is empty.
 
 Note the emit module step holds a shared lock for the time of the entire process lifetime, so only once the "pre-work" is finished, all other `xcswift-frontend` processes can continue their job (with either noop or fallbacking to the `swift-frontend` in case a cache miss). Non emit-module steps (compilation steps) acquire a lock only for a very short period - to read the content of that file, thus multiple batches of compilation can run in parallel.
 
-![Pre Swift Driver Integration](./../img/driver.png)
+<p>
+    <img src="docs/img/driver.png#gh-light-mode-only">
+    <img src="docs/img/driver-dark.png#gh-dark-mode-only">
+</p>
 
 <img src="./../img/sample-driver-timeline.png" width="600px">
 
 ### Sample timelines
 
-#### Emit Module acquires a lock first (common) 
+#### Emit Module acquires a lock first (common)
 
-![Swift Driver Integration Sample timeline](./../img/driver-scenario1.png)
+<p>
+    <img src="docs/img/driver-scenario1.png#gh-light-mode-only">
+    <img src="docs/img/driver-scenario1-dark.png#gh-dark-mode-only">
+</p>
 
-#### A compilation step acquires a lock first (uncommon but possible) 
+#### A compilation step acquires a lock first (uncommon but possible)
 
-![Swift Driver Integration Sample timeline](./../img/driver-scenario2.png)
+<p>
+    <img src="docs/img/driver-scenario2.png#gh-light-mode-only">
+    <img src="docs/img/driver-scenario2-dark.png#gh-dark-mode-only">
+</p>
 
 ### Other considerations/open questions