This patch extends llvm-dsymutil's ODR type uniquing machinery to also resolve forward decls for types defined in clang modules.
Details
Diff Detail
Event Timeline
Basically looks good. Some comments/questions:
tools/dsymutil/DwarfLinker.cpp | ||
---|---|---|
1665–1677 | I like the simplicity of adding modules as some kind of namespace. The fact that we hash the Tag here prevents us from uniquing what's in a module and standard namespaces. However the FIXME above only talks about backward compatibility. Maybe we should remove that FIXME and instead explain that it avoid conflicts between modules and other Decl scopes (and add a small note about preventing uniquing a struct with a class of the same name, but that this corner case doesn't warrant making that conditional). | |
1755–1756 | We should really rename that and change the comment (it should have done before, but your patch makes it even more meaningless). Maybe gatherInitialDIEInfo ? Or gatherDIEScopes ? Pick whichever you want (or an even more awesome name that I couldn't come up with). | |
1805–1810 | Wouldn't that logic always prune the TAG_module? or am I reading this wrong? | |
2223–2224 | I would have expected Prune to override Keep. What is the '&& !AlreadyKept' handling? |
Address review comments.
tools/dsymutil/DwarfLinker.cpp | ||
---|---|---|
1665–1677 |
Even if we wouldn't hash the Tag, we would still hash the module's name (NameRef) which is crucial in order to support (Obj)C because it is legal to have conflicting definitions for the same type in two differently named modules. In order to support uniquing in C++ between module types and other types, we should change clang to not emit C++ types inside a DW_TAG_module instead. | |
1755–1756 | I tried analyzeContextInfo(). We can still rename it if we can come up with something better. |
tools/dsymutil/DwarfLinker.cpp | ||
---|---|---|
1665–1677 |
Yes, I know that. I'm thinking of something different. Let's take a C++ program that uses a module called Foo. If the same program has a namespace called Foo (unrelated to the module), then we could have ODR uniquing collisions between unrelated things if we didn't hash the Tag. I'm just saying that we should promote the FIXME comment from a bug I wanted to remove to a feature that's needed. | |
1755–1767 |
Sounds good. | |
1805–1810 |
Sorry I misread the code. Can you add a comment to the function explaining the meaning of the return value please? |
test/tools/dsymutil/X86/modules.m | ||
---|---|---|
59–73 | Could you make all the CHECKs in this test a bit more rigorous? (some more CHECK-NOT DW_TAG|NULL) |
- made the tests stricter
- clarified comments
tools/dsymutil/DwarfLinker.cpp | ||
---|---|---|
1665–1677 | Got it now. I thought you were getting at that we aren't be able to unique types if one file imports a module and a second file is compiled without -fmodules and just #includes the module header. |
Could you make all the CHECKs in this test a bit more rigorous? (some more CHECK-NOT DW_TAG|NULL)