Once an LLVMContext has been told it needs to track pointer types, it can no longer be used to parse opaque modules. However, we are likely (at least for a while) to have old LTO .o files in the SDK that need to interoperate with just-generated ones, so deciding opaqueness based on the first module read causes linker failures.
This makes the llvm-c LTO interface (used by ld64) parse any object it sees in opaque mode, even if type data is present, which guarantees compatibility.
Hi - We noticed from out downstream embedded linker that this can be null if it comes in via lto_codegen_create, as opposed to lto_codegen_create_in_local_context.