This is the full implementation in Clang of the proposal:
http://lists.llvm.org/pipermail/llvm-dev/2015-December/093313.html
Details
- Reviewers
dblaikie ABataev echristo probinson aprantl - Commits
- rG30e7a8f694a1: Supporting all entities declared in lexical scope in LLVM debug info.
rC261634: Supporting all entities declared in lexical scope in LLVM debug info.
rL261634: Supporting all entities declared in lexical scope in LLVM debug info.
Diff Detail
Event Timeline
I don't feel comfortable enough with Clang to review the code part.
The tests are generally good (one inline comment) but it seems like they could be done all in one test file, which is more efficient in terms of test run time.
test/CodeGenCXX/debug-info-lb-static2.cpp | ||
---|---|---|
13 ↗ | (On Diff #44273) | I think the second check wants to end with scope: [[FuncScope]], (as written I think it's just redefining FuncScope). |
lib/CodeGen/CGDebugInfo.cpp | ||
---|---|---|
1479 | Dose this assert not fire if there are two decls in the same lexical scope? | |
1481 | Should we assert that LexicalBlockStack isn't empty? | |
1488 | Perhaps we should assert here that if D's scope is a lexical block, that it should have a corresponding entry in the LexicalBlockMap? | |
1489 | Why does the type need to be added to the retained types list? | |
1491 | else-after-return (just drop the else and let the following code remain unconditionally) | |
2066 | Would it be reasonable/possible to do these changes one at a time & demonstrate the different situations in which types were not correctly nested in lexical scopes? Or are they all necessary for some correctness/invariant that must hold? |
Thanks David for the feedback.
I have some answers below, please let me know if they are not sufficient or you are still have concerns.
lib/CodeGen/CGDebugInfo.cpp | ||
---|---|---|
1479 | Why two decls would have the same object instance "Decl"? | |
1481 | It might be empty, if the declaration is in the program scope, right? | |
1488 | We will get to this function also for D's that are not in lexical scope. I can agree with you that the function name is misleading, and I am open to other suggestions. | |
1489 | Excellent question :) Check line 518 at DwarfDebug.cpp (http://reviews.llvm.org/D15976#51cfb106) | |
2066 | Clang changes cannot be committed before the LLVM changes, otherwise we would crash in backend.
Now types can be split into several comments as well: Records and Typedef Regarding the test, I used to have 3 (even 4) separate tests, but I was asked to merged them. Now, what is your call? do you want me to commit the this patch in 3 steps? Or just go with it as one piece? |
Looks good to me. Test case could be simplified a bit further, but feel free to commit after that.
lib/CodeGen/CGDebugInfo.cpp | ||
---|---|---|
1479 | Right, I think I'm following now. I had some other ideas in my head that were wrong. | |
1481 | Yep, it's starting to make more sense to me now... | |
1489 | Not quite following - could we discover the types lazily as we're generating DWARF in the backend - if we happen to emit a variable of that type & generate the DIE* for the type, etc? (so that if a type becomes unused it's able to be dropped - rather than being preserved only when the type is local) I suppose that would make it difficult to choose which scopes we had to preserve when emitting debug info in the backend (if we didn't see a type until after the scope was created - we wouldn't've known whether to emit/create that scope or collapse it into its parent, etc) - so this probably isn't possible/practical. | |
2066 | Right, incremental patches that update the test case (test case could be committed as-is with CHECK-NOTs in places where the expected output didn't match the desired result, or with them removed & the types that are incorrect omitted until the functionality was added) But I think I'm understanding this mostly well enough for it go in as-is/in one go. | |
test/CodeGenCXX/debug-info-lb.cpp | ||
8 | Could just make this a struct. It probably doesn't need any members either. (simply "struct X { }") | |
15 | This block seems unnecessary, and its contents are probably more complicated than needed. This seems to suffice: X a; Y b; & the global variable is emitted without referencing it anyway. (you could drop the int return and x parameter, too - no need to return anything from the function, and the if (x) could be removed - the scope can remain & still produce the same debug info I think) |
Thanks David for the comments.
See answer below.
lib/CodeGen/CGDebugInfo.cpp | ||
---|---|---|
1489 | Your analysis is correct. I guess we can revisit this issue later and re-think a better implementation that make sure optimized types will not be emitted in the debug info. However, I think we can do that in a separate (following) patch. | |
test/CodeGenCXX/debug-info-lb.cpp | ||
15 | OK, I simplify the test, and it is still does what I needed. The only thing that I need to clarify is the extra block scope that I added to wrap the "a" and "b" variable definition. |
Looks good - though you could do that one further simplification to the test case, I think. (removing x/if x)
test/CodeGenCXX/debug-info-lb.cpp | ||
---|---|---|
5 | Looks like you could remove this "if (x)" and the "int x" parameter & still keep the test otherwise in tact. |
Dose this assert not fire if there are two decls in the same lexical scope?