[PATCH] D71219: Fix conflict value for metadata "Objective-C Garbage Collection" in the mix of swift and Objective-C bitcode

[John McCall via Phabricator via llvm-commits]

rjmccall added a comment.

Yes, the OBJC_IMAGE_INFO needs to include the information from the new module flag.

The basic situation here is not very complicated.  The OBJC_IMAGE_INFO contains information about the code present in the image, like the ObjC ABI in use, the Swift ABI in use, and whether ObjC GC is enabled.  In general, that information only applies to the subset of code that uses a particular language, but it does need to be consistent across all the code that uses that language.  Because Swift code on Darwin uses both the ObjC ABI and the Swift ABI, there's actually a sort of hierarchy here:

- C translation units don't care about either ABI
- ObjC translation units only care about the ObjC ABI
- Swift translation units care about both the ObjC and Swift ABIs

This can all be linked into the same image, and it's fine as long as the ObjC and Swift translation units all agree about the ObjC ABI details and all the Swift translation units agree about all the Swift ABI details.

This can be easily represented in LLVM module flags by using separate flags for each logical component, all with the `Error` behavior.   That's because `Error` requires the flag value to match if present in multiple translation units (thus achieving consistency among the translation units that care about an ABI), but also allows translation units to not provide the flag (thus permitting code to be linked in that doesn't care about an ABI).

This is currently subverted because, as a hasty convenience, we lumped the Swift ABI information into the GC flag.  This leads to a valid `OBJC_IMAGE_INFO` structure because of the details of how that structure is assembled, and the result is correctly handled by the Mach-O linker; however, it causes artificial problems for the LLVM IR linker by incorrectly preventing Swift translation units from being linked with ObjC translation units.  The solution is to stop lumping things into a single module flag so that LLVM doesn't have these artificial linking problems; instead, we should use separate module flags for the separate components.  But the basic requirement — to assemble all of this information into the emitted `OBJC_IMAGE_INFO` — will not change.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71219/new/

https://reviews.llvm.org/D71219