When an object file is in the Frameworks build phase of a static library target, don't add it to both the command line and the link-file-list of the libtool task.

This matches the behavior for ld of only putting it in the link-file-list.

Also modify some tests to check this behavior.

rdar://136958525

Author: mhrawdon

Sources/SWBCore/SpecImplementations/Tools/LinkerTools.swift

@@ -1530,9 +1530,8 @@ public final class LibtoolLinkerSpec : GenericLinkerSpec, SpecIdentifierType, @u
                 }
 
             case .object:
-                // A static library can bring in the contents of a .o file.
-                inputPaths.append(specifier.path)
-                return [specifier.path.str]
+                // Object files are added to linker inputs in the sources task producer and so end up in the link-file-list.
+                return []
 
             case .framework:
                 // A static library can build against a framework, since the library in the framework could be a static library, which is valid, and we can't tell here whether it is or not.  So we leave it to libtool to do the right thing here.

Tests/SWBCoreTests/CommandLineSpecTests.swift

@@ -1261,11 +1261,10 @@ import SWBMacro
         }
         var libraries = [LinkerSpec.LibrarySpecifier]()
         for kind in LinkerSpec.LibrarySpecifier.Kind.allCases {
-            guard kind != .object else {
-                continue
-            }
             libraries.append(contentsOf: generateLibrarySpecifiers(kind: kind))
         }
+        // This is a no-op because object files get added in the SourcesTaskProducer, but we want to confirm that this is the case.
+        libraries.append(LinkerSpec.LibrarySpecifier(kind: .object, path: Path.root.join("tmp/Bar.o"), mode: .normal, useSearchPaths: false, swiftModulePaths: [:], swiftModuleAdditionalLinkerArgResponseFilePaths: [:]))
 
         await linkerSpec.constructLinkerTasks(cbc, delegate, libraries: libraries, usedTools: [:])
 
@@ -1501,6 +1500,9 @@ import SWBMacro
             LinkerSpec.LibrarySpecifier(kind: .framework, path: Path.root.join("tmp/Foo2.framework"), mode: .weak, useSearchPaths: true, swiftModulePaths: [:], swiftModuleAdditionalLinkerArgResponseFilePaths: [:]),
             LinkerSpec.LibrarySpecifier(kind: .framework, path: Path.root.join("tmp/Foo3.framework"), mode: .normal, useSearchPaths: false, swiftModulePaths: [:], swiftModuleAdditionalLinkerArgResponseFilePaths: [:]),
             LinkerSpec.LibrarySpecifier(kind: .framework, path: Path.root.join("tmp/Foo4.framework"), mode: .weak, useSearchPaths: false, swiftModulePaths: [:], swiftModuleAdditionalLinkerArgResponseFilePaths: [:]),
+
+            // This is a no-op because object files get added in the SourcesTaskProducer, but we want to confirm that this is the case.
+            LinkerSpec.LibrarySpecifier(kind: .object, path: Path.root.join("tmp/Bar.o"), mode: .normal, useSearchPaths: false, swiftModulePaths: [:], swiftModuleAdditionalLinkerArgResponseFilePaths: [:]),
         ]
         await librarianSpec.constructLinkerTasks(cbc, delegate, libraries: libraries, usedTools: [:])
 

Tests/SWBTaskConstructionTests/TaskConstructionTests.swift

@@ -4966,7 +4966,7 @@ fileprivate struct TaskConstructionTests: CoreBasedTests {
                 TestBuildConfiguration("Debug", buildSettings: [
                     "PRODUCT_NAME": "$(TARGET_NAME)",
                     "CODE_SIGN_IDENTITY": "-",
-                    "ARCH": "x86_64",
+                    "ARCHS": "arm64",
                     "LIBTOOL": libtoolPath.str,
                 ]),
             ],
@@ -5049,8 +5049,8 @@ fileprivate struct TaskConstructionTests: CoreBasedTests {
                     task.checkNoInputs(contain: [.pathPattern(.suffix("libAnotherStatic.a"))])
                     // Check that the task does *not* declare libStaticLib2.a as an input, since it is located via search paths.  Some projects may have a file reference whose path does not refer to a file, but which relies on finding the library via search paths anyway.
                     task.checkNoInputs(contain: [.pathPattern(.suffix("libStaticLib2.a"))])
-                    // Check that the task contains a command line option to link Object.o, and declares it as an input.
-                    task.checkCommandLineContains(["\(SRCROOT)/Object.o"])
+                    // Check that the task does *not* contain a command line option to link Object.o (it will be in the LinkFileList instead, checked below), but that it *does* declare it as an input.
+                    task.checkCommandLineDoesNotContain("\(SRCROOT)/Object.o")
                     task.checkInputs(contain: [.path("\(SRCROOT)/Object.o")])
 
                     // Check that the task does *not* have a command line option to find libDynamicLib1.dylib, nor does it declare it as an input, because static libraries can't link against dynamic libraries.  We presently don't emit a diagnostic for this - see LibtoolLinkerSpec.constructLinkerTasks() and <rdar://problem/34314195> for more.
@@ -5059,6 +5059,16 @@ fileprivate struct TaskConstructionTests: CoreBasedTests {
 
                     task.checkOutputs(contain: [.path("\(SRCROOT)/build/Debug/libStaticLib1.a")])
                 }
+
+                // Check the contents of the LinkFileList.
+                results.checkWriteAuxiliaryFileTask(.matchTarget(target), .matchRuleType("WriteAuxiliaryFile"), .matchRuleItemPattern(.suffix("/StaticLib1.LinkFileList"))) { task, contents in
+                    task.checkRuleInfo(["WriteAuxiliaryFile", "\(SRCROOT)/build/aProject.build/Debug/StaticLib1.build/Objects-normal/arm64/StaticLib1.LinkFileList"])
+                    let contentsLines = contents.asString.dropLast().components(separatedBy: .newlines)
+                    #expect(contentsLines == [
+                        "\(SRCROOT)/build/aProject.build/Debug/StaticLib1.build/Objects-normal/arm64/File.o",
+                        "\(SRCROOT)/Object.o",
+                  ])
+                }
             }
 
             results.checkTarget("StaticLib2") { target in