Fix typos

Author: polac24

Sources/XCRemoteCache/Commands/SwiftFrontend/SwiftFrontendContext.swift

@@ -26,15 +26,15 @@ struct SwiftFrontendContext {
 
 extension SwiftFrontendContext {
     init(_ swiftcContext: SwiftcContext, env: [String: String]) throws {
-        /// The LLBUILD_BUILD_ID ENV that describes the swiftc (parent) invocation
+        /// The LLBUILD_BUILD_ID ENV that describes the entire (incl. parent's swiftc) bui;d
         let llbuildId: String = try env.readEnv(key: "LLBUILD_BUILD_ID")
         invocationLockFile = Self.self.buildLlbuildIdSharedLockUrl(
             llbuildId: llbuildId,
             tmpDir: swiftcContext.tempDir
         )
     }
 
-    /// Generate the filename to be used to sycnhronize mutliple swift-frontend invocations
+    /// Generate the filename to be used to synchronize multiple swift-frontend invocations
     /// The same file is used in prebuild, xcswift-frontend and postbuild (to clean it up)
     static func buildLlbuildIdSharedLockUrl(llbuildId: String, tmpDir: URL) -> URL {
         return tmpDir.appendingPathComponent(llbuildId).appendingPathExtension("lock")

Sources/XCRemoteCache/Commands/SwiftFrontend/SwiftFrontendOrchestrator.swift

@@ -21,15 +21,15 @@ import Foundation
 
 /// Manages  the `swift-frontend` logic
 protocol SwiftFrontendOrchestrator {
-    /// Executes the criticial secion according to the required order
+    /// Executes the critical section according to the required order
     /// - Parameter criticalSection: the block that should be synchronized
     func run(criticalSection: () -> Void ) throws
 }
 
 /// The default orchestrator that manages the order or swift-frontend invocations
-/// For emit-module (the "first" process) action, it locks a shared file between all swift-frontend invcations,
-/// verifies that the mocking can be done and continues the mocking/fallbacking along the lock release
-/// For the compilation action, tries to ackquire a lock and waits until the "emit-module" makes a decision
+/// For emit-module (the "first" process) action, it locks a shared file between all swift-frontend invocations,
+/// verifies that the mocking can be done and continues the mocking/fall-backing along the lock release
+/// For the compilation action, tries to acquire a lock and waits until the "emit-module" makes a decision
 /// if the compilation should be skipped and a "mocking" should used instead
 class CommonSwiftFrontendOrchestrator {
     /// Content saved to the shared file
@@ -78,7 +78,7 @@ class CommonSwiftFrontendOrchestrator {
     }
 
 
-    /// Foor emit-module, wrap the critical section with the shared lock so other processes (compilation)
+    /// For emit-module, wrap the critical section with the shared lock so other processes (compilation)
     /// have to wait until emit-module finishes
     /// Once the emit-module is done, the "magical" string is saved to the file and the lock is released
     ///
@@ -95,8 +95,8 @@ class CommonSwiftFrontendOrchestrator {
         try lockAccessor.exclusiveAccess { handle in
             debugLog("starting the emit-module step: locked")
             // writing to the file content proactively - incase the critical section never returns
-            // (in case of a fallback to the local compilation), all awaiting swift-frontent processes
-            // will be immediatelly unblocked
+            // (in case of a fallback to the local compilation), all awaiting swift-frontend processes
+            // will be immediately unblocked
             handle.write(Self.self.emitModuleContent)
             try criticalSection()
             debugLog("lock file emit-module criticial end")
@@ -126,7 +126,7 @@ class CommonSwiftFrontendOrchestrator {
             if !executed && Date().timeIntervalSince(startingDate) > self.maxLockTimeout {
                 errorLog("""
                 Executing command \(action) without lock synchronization. That may be cause by the\
-                crashed or extremly long emit-module. Contact XCRemoteCache authors about this error.
+                crashed or extremely long emit-module. Contact XCRemoteCache authors about this error.
                 """)
                 try criticalSection()
                 executed = true

Sources/XCRemoteCache/Dependencies/CacheModeController.swift

@@ -124,7 +124,7 @@ class PhaseCacheModeController: CacheModeController {
     // this is just a non-critical cleanup step to not leave {{LLBUILD_BUILD_ID}}.lock
     // files in $TARGET_TEMP_DIR. It is expected that both prebuild and postbuild will
     // invoke it, to ensure:
-    // - swift-frontent synchronization is done per-target build
+    // - swift-frontend synchronization is done per-target build
     // - no .lock leftover files
     private func cleanupLlBuildLock() throws {
         if fileManager.fileExists(atPath: llbuildLockFile.path) {

Sources/xcswift-frontend/XCSwiftcFrontendMain.swift

@@ -29,13 +29,13 @@ public class XCSwiftcFrontendMain {
     // swiftlint:disable:next function_body_length cyclomatic_complexity
     public func main() {
         let env = ProcessInfo.processInfo.environment
-        // Do not invoke raw swift-frontend because that would lead to the invifnite loop
+        // Do not invoke raw swift-frontend because that would lead to the infinite loop
         // swift-frontent -> xcswift-frontent -> swift-frontent
         //
         // Note: Returning the `swiftc` executaion here because it is possible to pass all arguments
-        // from swift-frontent to `swiftc` and swiftc will be able to redirect to swift-frontend
+        // from swift-frontend to `swiftc` and swiftc will be able to redirect to swift-frontend
         // (because the first argument is `-frontend`). If that is not a case (might change in
-        // future swift compiler versions), invoke swift-frontent from the Xcode, but that introduces
+        // future swift compiler versions), invoke swift-frontend from the Xcode, but that introduces
         // a limitation that disallows custom toolchains in Xcode:
         // $DEVELOPER_DIR/Toolchains/XcodeDefault.xctoolchain/usr/bin/{ ProcessInfo().processName}
         let command = "swiftc"
@@ -110,7 +110,7 @@ public class XCSwiftcFrontendMain {
             docPath: docPath,
             supplementaryOutputFileMap: supplementaryOutputFileMap
         )
-        // swift-frontened is first invoked with some "probing" args like
+        // swift-frontend is first invoked with some "probing" args like
         // -print-target-info
         guard emitModule != compile else {
             runFallback(envs: env)

Tests/XCRemoteCacheTests/Commands/SwiftFrontendOrchestratorTests.swift

@@ -34,7 +34,7 @@ final class SwiftFrontendOrchestratorTests: FileXCTestCase {
         try fileManager.write(toPath: emptyFile.path, contents: .init())
     }
 
-    func testRunsCriticalSectionImmediatellyForProducer() throws {
+    func testRunsCriticalSectionImmediatelyForProducer() throws {
         let orchestrator = CommonSwiftFrontendOrchestrator(
             mode: .producer,
             action: .compile,
@@ -49,7 +49,7 @@ final class SwiftFrontendOrchestratorTests: FileXCTestCase {
         XCTAssertTrue(invoked)
     }
 
-    func testRunsCriticalSectionImmediatellyForDisabledConsumer() throws {
+    func testRunsCriticalSectionImmediatelyForDisabledConsumer() throws {
         let orchestrator = CommonSwiftFrontendOrchestrator(
             mode: .consumer(commit: .unavailable),
             action: .compile,

docs/design/SwiftDriverIntegration.md

@@ -1,19 +1,21 @@
 ## Swift Driver Integration
 
-### Pre Swift Driver Integraiton 
+### 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 passed all required parameters (like all input files, output destinations, header paths etc.), and read its standard output to recognize the status of a compilation. Esentially, there were two build systems: "the big one" from Xcode and "small one" by Swift.
+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 using 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 continued with the local compilation or mocking the compilation and existing early (cache hit).
+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)
 
 
 ### Swift Driver Integration Design
 
-With the upgraded design, Xcode splits the work into `n` subprocesses (when `n` is ~CPU), each responsible to compile a subset of files/actions. To mitigate that, XCRemoteCache sets a single place to identify if the cached artifact is applicable - in a `swift-frontend` process responsible for module emitting. It has been found that this process is scheduled very early int the workflow timeline (with some aproximation, we could say it is scheduled as a first step) so it seems as best candidate for the "pre-work". 
+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 is invoked multiple times for the same target (emit module, and multiple batches of compilation), XCRemoteCaches uses a file lock-based synchronization. Each `xcswift-frontend` (the wrapper for `swift-frontend`) tries to acquire a target-unique lock file (the file has a name equal to the `LLBUILD_BUILD_ID` ENV, which is unique for each build, and the file is placed in the `Intermediate` directory) and reads its content to find if the "pre-work" from the emit-module has been already done or not. As a lock file is unique per target and a build (it is actually unique per target compilation, as placed in `TARGET_TEMP_DIR`), initially the file is empty. If any of a non emit module invocation sees a file is empty (note that before reading, it acquires a shared lock), the lock is immediatelly released to quickly let the actual emit-module wrapper do the "pre-work". 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 (wither noop or fallbacking to the `swift-frontent` in case a cache miss). Non emit-module steps (often, but not exclusive, compilation steps) acquire a lock only for a very short perdio - to read the content of that file so they could run in parallel.s
+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)
 
@@ -31,5 +33,5 @@ As the same executable is invoked multiple times for the same target (emit modul
 
 ### Other considerations/open questions
 
-* For mixed targets (ObjC&Swift), Xcode triggers `.m` compilation steps after the module emitting to ensure that the `-Swift.h` is available. That means, the synchronization algorithm will also postpone any `clang` invocations until the Swift "pre-work" is done - so mixed targets should behave the same way as in the non Swift Driver Integration flow
-* For the WMO mode (Whole Module Optimization), all compilation steps are combined into a single `swift-frontend` process. As the emit module step is still invoked first, the WMO flow build builds down to a special case of the non-WMO. Therefore, the same algoritm should work for WMO builds too.
+* For mixed targets (ObjC&Swift), Xcode triggers `.m` compilation steps **after** the module emitting to ensure that the `-Swift.h` is available for clang compilation. That means, the synchronization algorithm will postpone any `clang` invocations until the Swift "pre-work" is done. Therefore, mixed targets should behave the same way as in the non Swift Driver Integration flow
+* For the WMO (Whole Module Optimization) mode, all compilation steps are combined into a single `swift-frontend` process. As the emit-module step is still invoked first, the WMO flow build can be considered as a special case of the algorithm described above (where there is only one compilation invocation). Therefore, the presented algorithm will work for the WMO mode out of the box.