Resolve https://github.com/llvm/llvm-project/issues/61932. We should add the validation.
LLVM can't handle IR where subprogram definitions are nested within DICompositeType when doing LTO builds, because there's no good way to cross the CU boundary to insert a nested DISubprogram definition in one CU into a type defined in another CU.
The test cases cross-cu-inlining-2.ll and cross-cu-inlining-ranges.ll can be deleted. In the cross-cu-inlining-2.ll, the low pc and high pc of the CU are also incorrect.
This looks a bit confused - it's claiming to be a definition, but it's not referenced by any llvm Function - and then it's referencing a declaration? Perhaps these functions should not have the definition flag?
@aprantl @JDevlieghere what's the Swift IR look like today? Does it put subprogram definitions within composite types? That's not ideal/bit likely to break under LTO builds & would you be amenable to changing that to indirect through a definition that's outside the composite type to a declaration in the composite type?