Don't use package manifest to treat warnings as errors

This reverts the configuration changes from a78e4ae. It turns out that
this is causing a compilation error of "error: conflicting options
'-warnings-as-errors' and '-suppress-warnings'" when trying to use Xcode
to build an app that uses the SDK.

Will create a minimal reproduction and raise a bug with Apple (have
created #441 for this and restoring a78e4ae once fixed).

I'm not sure why our example app wasn't catching this, but I guess there
must be a difference in the way that the SDK gets built when it's
included in the SDK via a workspace as opposed to via SPM. I've created
#442 for for making the example app build more realistic to try and
catch this sort of issue in the future; tried doing it as part of this
work but didn't find a good solution, and want to get this fix released.

Resolves #436.

Author: lawrence-forooghian

.github/workflows/check.yaml

@@ -91,9 +91,10 @@ jobs:
         with:
           xcode-version: ${{ matrix.tooling.xcodeVersion }}
 
-      - run: swift build
+      # https://forums.swift.org/t/warnings-as-errors-for-libraries-frameworks/58393/2
+      - run: swift build -Xswiftc -warnings-as-errors
       # Disabling testing temporarily due to intermittent hangs on CI (https://github.com/ably/ably-chat-swift/issues/295)
-      #- run: swift test
+      #- run: swift test -Xswiftc -warnings-as-errors
 
   build-release-configuration-spm:
     name: SPM, `release` configuration (Xcode ${{ matrix.tooling.xcodeVersion }})
@@ -111,7 +112,8 @@ jobs:
         with:
           xcode-version: ${{ matrix.tooling.xcodeVersion }}
 
-      - run: swift build --configuration release
+      # https://forums.swift.org/t/warnings-as-errors-for-libraries-frameworks/58393/2
+      - run: swift build -Xswiftc -warnings-as-errors --configuration release
 
   build-and-test-xcode:
     name: Xcode, ${{matrix.platform}} (Xcode ${{ matrix.tooling.xcodeVersion }})

Package.swift

@@ -3,7 +3,6 @@
 import PackageDescription
 
 let commonSwiftSettings: [SwiftSetting] = [
-    .treatAllWarnings(as: .error),
     .enableUpcomingFeature("MemberImportVisibility"),
     .enableUpcomingFeature("ExistentialAny"),
 ]

Sources/BuildTool/XcodeRunner.swift

@@ -24,6 +24,46 @@ enum XcodeRunner {
             arguments.append(contentsOf: ["-resultBundlePath", resultBundlePath])
         }
 
+        /*
+         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).
+
+         (I imagine that using .unsafeFlags(["-warnings-as-errors"]) in the
+         manifest might work, but then that’d stop other people from being able
+         to use us as a dependency. I suppose we could, in CI at least, do
+         something like modifying the manifest as part of the build process, but
+         that seems like a nuisance.)
+         */
+
         try await ProcessRunner.run(executableName: "xcodebuild", arguments: arguments)
     }
 }