This patch adds a DIModule debug info metadata node to the IR. It is meant to be used to record modules @imported by the current compile unit, so a debugger an import the same modules to replicate this environment before dropping into the expression evaluator.
DIModule is a sibling to DINamespace and behaves quite similarly. In addition to the name of the module it also records the module configuration details that are necessary to uniquely identify the module. This includes the configuration macros (e.g., -DNDEBUG), the include path where the module.map file is to be found, and the isysroot.
The idea is that the backend will turn this into a DW_TAG_module. The DW_AT_LLVM_* attributes holding the configuration strings can either be emitted into the DW_TAG_module or as part of the skeleton CU depending on how we decide to move forward on this.
Would it be better to make the contents of the module more opaque/generic? I'm not sure - don't know how authoritative these 4 properties {name, config macros, include path(s?), isysroot} is - if we're likely to later need other things, etc. I mean I know the schema is more forwards-compatible by adding new fields, but equally it's a lot of churn to change the schema now, so if these are just an opaque bundle of things that only have meaning to the frontend anyway, I'm wondering if they should be handled as such.