On Windows, we need to emit symbols which may be multiply defined in COMDATs to ensure that the symbol is uniqued by the linker. This is normally fine, and in a couple of sites where we generate declarations only, we remove the COMDAT associated with the declaration. However, when generating the type metadata, we are failing to remove the COMDAT associated with a declaration only which results in invalid IR.
Now, the interesting thing is that we generate the symbol for the type metadata multiple times, but, because the type metadata may be emitted lazily, we don't necessarily know if we are going to actually emit the symbol. It may just be a nominal type which is going to be lazy emitted or it could be eagerly emitted. I can’t seem to identify which case we are currently in. Erasing the COMDAT eagerly fails as the symbol is not emitted, and leaving the COMDAT means that we end up with cases of declarations only getting marked as COMDAT, which is invalid IR. Erasing the COMDAT at the time of the construction of the variable declaration doesn’t really work very well due to the definition being attached later.
One idea that I had (but failed) was to eagerly erase the COMDAT, and associate the COMDAT by re-applying the IR Linkage at the lazy definition time. However, that seems to abort during the standard library build (I’ve not thoroughly analyzed why).
This results in the multithreaded builds failing (which I had seen once but had disappeared). Now that this is reproducible, it would be great to fix this. I am rather perplexed with this at this point and would appreciate some pointers.