Fix lldb when using `experimental_mixed_language_library`

[brentleyjones]

This applies a similar fix that https://github.com/buildbuddy-io/rules_xcodeproj/commit/d40173d84764c1256b95a537b2871e010398f18c did, for the same reason.

[brentleyjones]

I probably have to make a couple more tweaks, but the key thing is that only the objc custom modulemap ends up downstream -Xcc flags. I'll add a test around this behavior as well.

[brentleyjones]

@thii Do you know of an example where this breaks?

[brentleyjones]

I think I'll also try to have a single umbrella modulemap created instead (one that doesn't depend on the swift_library, but still has the generated header entry), as that would solve this problem as well: https://github.com/buildbuddy-io/rules_xcodeproj/blob/main/docs/faq.md#why-do-some-of-my-swift_librarys-compile-twice-in-bwx-mode

[thii]

I think umbrella_module_map is the correct one, otherwise an objc_library won't be able to see the interface of the underlying Swift module. (I forgot to add an example to check it.)

On why lldb breaks, I think it's because the generated Swift header always have this kind of import statement:

#import <MyMixedModule/MyMixedModule.h>

and if you don't have codebase structure that makes this work, or proper -I flags, or header maps, then lldb won't be able to find MyMixedModule.h.

Edit: Obj-C umbrella header import statement in Swift generated header, not Swift generated header import statement.

[brentleyjones]

I'll try the single module map method instead then Monday.

[thii]

Edit: It was the Obj-C umbrella header import statement in the Swift generated header, not the Swift generated header import statement within itself.

Updated the above comment as well.

[brentleyjones]

The lldb issue is because later swift_library's get the umbrella modulemap in -fmodule-map-file=, while the inner one gets the non-umbrella version, and lldb collects all -Xcc flags down the dependency tree, leading to modulemap redefinition errors.

I think the proper fix is that we need two module maps to get propagated:

• MODULE.modulemap, with just the ObjC stuff
• MODULE.swift.modulemap, with just the MODULE.swift Swift sutff

And that way both are seen and depended on down stream.

I don't get how modulemaps are used with Bazel compilation though, as I couldn't get a dependent objc_library to see the modulemap created by this macro. So I think someone else will have to take on this fix.

[thii]

IIRC it was done like that so that we didn't have to change our import statements during the migration to Bazel. For example @import MixedModule; would also import the Swift interface of the mixed module. But if you only care about building with Bazel then this change makes sense.

Now thinking about it again, I guess this might have been the reason of many of our lldb issues in the past.

[brentleyjones]

Does this change work for you too @chiragramani?

[chiragramani]

Does this change work for you too @chiragramani?

We have a slightly different implementation, but I think the root cause you highlighted would also fix our case. I will check and let you know. Thanks!