Fix Swift Compiler Modules support in Debug mode (#73506)

The new `swift-driver` seems to enqueue a `wrapmodule` job which uses
the given `module-name` to form the output file name when not doing
optmizations (seems to happen only for `-Onone` in my testing). Since the
CMake functions macros are using the module name also as the explicit output
name, this clashes and ends up in an unhelpful error message from the driver.

```
SwiftDriverExecution/MultiJobExecutor.swift:207: Fatal error: multiple
producers for output ... SwiftCompilerSources/Basic.o: Wrapping Swift
module Basic & Compiling Basic SourceLoc.swift
```

This was reported in https://forums.swift.org/t/debug-swift-build-fails/71380

The changes use a different output object name (by using `.object.o`
suffix) which does not clash with what the `swift-driver` does
automatically. The code around the output objects and the static
libraries have to change slightly to handle this case.

Additionally, the resulting library when in `Debug` is now declaring its
dependency on `swiftSwiftOnoneSupport`, to avoid linking errors when the
libraries are used in the final binaries.

Debug mode seems to enable PURE_BRIDGING_MODE, which seems to skip
transitively including some C headers that files like
`Utilities/Test.swift` depend on. To avoid errors building, add the
missing include in a new `#else` branch.

I think CI will not test the `Debug` mode, so the only thing that it can prove is
that these changes do not break the `Release` mode.

Author: drodriguez

SwiftCompilerSources/CMakeLists.txt

@@ -204,11 +204,20 @@ function(add_swift_compiler_modules_library name)
       endforeach()
     endif()
 
-    set(module_obj_file "${build_dir}/${module}.o")
+    if(CMAKE_BUILD_TYPE STREQUAL "Debug" AND NOT SWIFT_HOST_VARIANT_SDK IN_LIST SWIFT_DARWIN_PLATFORMS)
+      # swift-driver when non-optimizing in not Mach-O  platforms adds an extra
+      # job wrapmodule that uses the {module-name}.o as output, which clashes
+      # with the name chosen here. Use a different name in those cases.
+      set(module_obj_file "${build_dir}/${module}.object.o")
+      set(output_obj_files "${module_obj_file}" "${build_dir}/${module}.o")
+    else()
+      set(module_obj_file "${build_dir}/${module}.o")
+      set(output_obj_files "${module_obj_file}")
+    endif()
     set(module_file "${build_dir}/${module}.swiftmodule")
     list(APPEND all_module_files ${module_file})
 
-    set(all_obj_files ${all_obj_files} ${module_obj_file})
+    list(APPEND all_obj_files ${output_obj_files})
     set(c_include_paths
       # LLVM modules and headers.
       "${LLVM_MAIN_INCLUDE_DIR}"
@@ -237,7 +246,7 @@ function(add_swift_compiler_modules_library name)
         ${c_include_paths_args}
         # Generated swift modules.
         "-I" "${build_dir}"
-      OUTPUT ${module_obj_file}
+      OUTPUT ${output_obj_files}
       WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
       DEPENDS ${sources} ${deps} ${ALS_DEPENDS}
         importedHeaderDependencies
@@ -260,6 +269,9 @@ function(add_swift_compiler_modules_library name)
   add_library(${name} STATIC ${all_obj_files})
   add_dependencies(${name} ${all_module_targets})
   set_target_properties(${name} PROPERTIES LINKER_LANGUAGE CXX)
+  if(CMAKE_BUILD_TYPE STREQUAL "Debug")
+    target_link_libraries(${name} PUBLIC swiftSwiftOnoneSupport)
+  endif()
 
   # Downstream linking should include the swiftmodule in debug builds to allow lldb to
   # work correctly. Only do this on Darwin since neither gold (currently used by default

include/swift/SILOptimizer/OptimizerBridging.h

@@ -388,6 +388,9 @@ void SILCombine_registerInstructionPass(BridgedStringRef instClassName,
 #ifndef PURE_BRIDGING_MODE
 // In _not_ PURE_BRIDGING_MODE, briding functions are inlined and therefore inluded in the header file.
 #include "OptimizerBridgingImpl.h"
+#else
+// For fflush and stdout
+#include <stdio.h>
 #endif
 
 SWIFT_END_NULLABILITY_ANNOTATIONS