[dsymutil] Fix parallel linker's self-recursive typedef DIE

[royitaqi]

The root cause of #162954 is that the two typedef DIEs are merged into one. This is because their synthetic names are the same (see below). The (same) synthetic names are then used as the hash key of the type pool in the (output) artificial type unit (code), making the two input DIEs to both be paired with the same output DIE.

CompileUnit::assignTypeNamesRec(): current child = 0x00000044
SyntheticTypeNameBuilder::addDIETypeName():
    added parent name. SyntheticName =
    added type prefix. SyntheticName ={H}
    added type name. SyntheticName ={H}BarInt   <-- Same synthetic name
    assigned to type descriptor. TypeEntryPtr = 0x0x13300a018   <-- It's the same type entry object

CompileUnit::assignTypeNamesRec(): current child = 0x0000004c
SyntheticTypeNameBuilder::addDIETypeName():
    added parent name. SyntheticName =
    added type prefix. SyntheticName ={H}
    added type name. SyntheticName ={H}BarInt   <-- Same synthetic name
    assigned to type descriptor. TypeEntryPtr = 0x0x13300a018   <-- It's the same type entry object

A solution would be to differentiate the two input DIEs' synthetic names, so that they generate different output DIEs, so that they end up being two DIEs the linked DWARF.

This patch implements said solution by adding decl file and line into the synthetic names. This is done only for typedef DIEs to minimize the change. Note that, in order for the bug to be fixed, we depend on #166673 to be fixed, too, so that the decl lines will be different for these two typedefs (currently they are both 3, so the synthetic name is still the same even with decl file/line added). Note that the usage of addDieNameFromDeclFileAndDeclLine() is hopefully not evil - see line 339 use it as a last resort if no synthetic name is generated already.

A different implementation (implemented in #166767) can be to call addReferencedODRDies() (just 10 lines below my change) to add the referenced types into the synthetic name (hopefully recursively). The advantage of this solution is that 1) the resultant synthetic name is more "correct" (see caveat of the first approach below), and, 2) it doesn't depend on #166673 to be fixed.

The two implementations have different caveats. The first won't work if there are two typedefs of the same name on the same source line. Not typical, but happens. The second won't work if any of the referenced types resolve to the same name for some reason (similar to how the two typedefs resolved to the same name in this case).

[Michael137]

Conceptually it makes sense to not merge the DIEs since they aren't the same. Also typedefs are the only construct that i can think of atm that would allow two distinct entities with the same name. I guess technically it's a redeclaration?

I dont think we should look at line numbers though. For one, a dwarf producer may omit them. And as you say, two typedefs may be declared on the same line

Could we include the canonical referred-to type in the synthetic name? I.e unwrap the typefed type?

[royitaqi]

Could we include the canonical referred-to type in the synthetic name? I.e unwrap the typefed type?

Thanks for the advice. IIUC, that's the "different implementation" mentioned in the description of this patch.

I have just implemented it in #166767. Would love your review there.