From 258bb872d365816c0262d3a06b18e1e214aad095 Mon Sep 17 00:00:00 2001
From: Lawrence Forooghian <lawrence@forooghian.com>
Date: Thu, 22 Aug 2024 17:34:25 +0100
Subject: [PATCH] well turn it all off i guess

---
 Sources/BuildTool/XcodeRunner.swift | 36 +++++++++++++++++++++++++++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/Sources/BuildTool/XcodeRunner.swift b/Sources/BuildTool/XcodeRunner.swift
index db5d7c02..45973890 100644
--- a/Sources/BuildTool/XcodeRunner.swift
+++ b/Sources/BuildTool/XcodeRunner.swift
@@ -11,8 +11,40 @@ enum XcodeRunner {
 
         arguments.append(contentsOf: ["-scheme", scheme])
         arguments.append(contentsOf: ["-destination", destination.xcodebuildArgument])
-        arguments.append("SWIFT_TREAT_WARNINGS_AS_ERRORS=YES")
-        arguments.append("SWIFT_SUPPRESS_WARNINGS=NO")
+
+        /*
+         Note: I was previously passing SWIFT_TREAT_WARNINGS_AS_ERRORS=YES here, but am no longer able to do so, for the following reasons:
+
+         1. After adding a new package dependency, Xcode started trying to pass
+            the Swift compiler the -suppress-warnings flag when compiling one of
+            the newly-added transitive dependencies. This clashes with the
+            -warnings-as-errors flag that Xcode adds when you set
+            SWIFT_TREAT_WARNINGS_AS_ERRORS=YES, leading to a compiler error like
+
+            > error: Conflicting options '-warnings-as-errors' and '-suppress-warnings' (in target 'InternalCollectionsUtilities' from project 'swift-collections')
+
+            It’s not clear _why_ Xcode is adding this flag (see
+            https://forums.swift.org/t/warnings-as-errors-in-sub-packages/70810),
+            but perhaps it’s because of what I mention in point 2 below.
+
+            It seems that there is no way to tell Xcode, when building your own
+            Swift package, “treat warnings as errors, but only for my package, and
+            not for its dependencies”.
+
+         2. So, I thought that I’d try making Xcode remove the
+            -suppress-warnings flag by additionally passing
+            SWIFT_SUPPRESS_WARNINGS=NO, but this also doesn’t work because it turns
+            out that one of our dependencies (swift-async-algorithms) actually does
+            have some warnings, causing the build to fail.
+
+         tl;dr: There doesn’t seem to be a way to treat warnings as errors when
+         compiling the package from Package.swift using Xcode.
+
+         It’s probably OK, though, because we also compile the package with SPM,
+         and hopefully that will flag any warnings in CI (unless there’s some
+         class of warnings I’m not aware of that only appear when compiling
+         against the tvOS or iOS SDK).
+         */
 
         if let exampleAppSwiftVersion {
             arguments.append(