[cxx-interop] Emit -enable-experimental-cxx-interop flag into the module interface

[egorzhdan]

This makes sure that when Swift is generating a .swiftinterface file for a Swift module with a dependency on C++ module, -enable-experimental-cxx-interop is emitted under // swift-module-flags:.

The module interface might refer to C++ symbols which are not available in Swift without C++ interop enabled. This caused a build error for Swift LLVM bindings during verify-module-interface stage: Swift tried to import the module interface and couldn't find C++ stdlib headers because C++ interop was disabled.

<module-includes>:1:9: note: in file included from <module-includes>:1:
#import "Support/ConvertUTF.h"
        ^
/Volumes/Projects/swift/llvm-project/llvm/include/llvm/Support/ConvertUTF.h:92:10: error: 'cstddef' file not found
#include <cstddef>
         ^
Sources/LLVM/LLVM_Utils.swiftinterface:4:19: error: could not build Objective-C module 'LLVM_Utils'
@_exported import LLVM_Utils
                  ^
Sources/LLVM/LLVM_Utils.swiftinterface:1:1: error: failed to verify module interface of 'LLVM_Utils' due to the errors above; the textual interface may be broken by project issues or a compiler bug
// swift-interface-format-version: 1.0
^
<unknown>:0: error: verify-module-interface command failed with exit code 1 (use -v to see invocation)

[egorzhdan]

I renamed the module to avoid name collision: both the namespace and its containing module were called Namespace. This is a general Swift issue that can be worked around by passing -module-interface-preserve-types-as-written flag.

[egorzhdan]

@swift-ci please smoke test

[hyp]

Why do the Swift LLVM bindings need a module interface file in the first place? Are they going to be ABI stable and require library evolution because of that?

[egorzhdan]

@hyp good question, I think we don't really need library evolution for the bindings, at least for now. So this change shouldn't be a requirement for the bindings to work, but users might hit this error in other projects.

[bnbarham]

Should this be emitted in the module interface, or should we pass it along when building modules from their interface when the original command has it enabled?

If I don't have experimental C++ interop enabled and I depend on a module that requires it, I think I'd expect building that module to fail rather than to build with interop 🤔?

Any thoughts @xymus?

[xymus]

Printing the flag in the swiftinterface makes sense to keep it self contained and buildable/verifiable on its own. Making the swiftinterface build options depend on its clients would require a different cache hash, I don't think it's worth it here.

[xymus]

It would be interesting to verify that the generated swiftinterface can be parsed. There are macros for that, here's a sample usage:

// RUN: %target-swift-emit-module-interface(%t/Original.swiftinterface) %t/Original.swift
// RUN: %target-swift-typecheck-module-from-interface(%t/Original.swiftinterface)

[egorzhdan]

Thanks, I didn't know about these macros. Added target-swift-typecheck-module-from-interface as well.

[egorzhdan]

@swift-ci please smoke test

[egorzhdan]

@swift-ci please smoke test macOS

[xymus]

Thanks for adding the swiftinterface verification!

You may want to keep an eye on references to anything put in the bridging header like namespace members and templates. I would expected them to be printed under the module name __ObjC and break the swiftinterface.

[egorzhdan]

You may want to keep an eye on references to anything put in the bridging header like namespace members and templates. I would expected them to be printed under the module name __ObjC and break the swiftinterface.

Hmm, I think we have logic in the module interface printer tailored for namespaces that makes sure they namespaces' members are printed in the module which they are declared in.
We should probably have tests for this, I'll add some in another PR. Thanks for bringing it up!