Follow-up from D72589.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Unit tests: pass. 62283 tests passed, 0 failed and 827 were skipped.
clang-tidy: pass.
clang-format: pass.
Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml
Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.
Unit tests: pass. 62322 tests passed, 0 failed and 838 were skipped.
clang-tidy: pass.
clang-format: pass.
Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml
Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.
llvm/utils/gdb-scripts/prettyprinters.py | ||
---|---|---|
322–325 | I think I asked this elsewhere, but not sure there was an answer (apologies if I forgot - might be worth a comment) - what is this error case for? Are there types in LLVM that don't provide this expected nested type? Might be nice if it could be removed & then wouldn't need the factory layer of indirection for PointerIntPair and PointerUnion below. |
llvm/utils/gdb-scripts/prettyprinters.py | ||
---|---|---|
322–325 | GDB gets confused about template arguments of 'std::_u::pair' (not sure I remember the exact name), and the lookup_type may fail. Unfortunately GDB spews the console when a printer factory throws an exception, so it's better to catch it and handle it. I will add a comment. |
llvm/utils/gdb-scripts/prettyprinters.py | ||
---|---|---|
322–325 | Where does std::pair come into this? The 4th template argument to PointerIntPair is the PointerLikeTypeTraits, right? |
llvm/utils/gdb-scripts/prettyprinters.py | ||
---|---|---|
322–325 | It's zero-based, so it's the PointerIntPairInfo, and if PointerTy is a std::pair<...>* gdb fails to look up the type. Something like that. Is it important enough to dig up the details? |
llvm/utils/gdb-scripts/prettyprinters.py | ||
---|---|---|
322–325 | Given the existence of this error path adds complexity to how this function is used, error paths to its callers, etc - yeah, I'd like to know why it's there & have a test case for it if it's needed (but hope there might be other solutions to addressing the underlying issue that might allow the error handling to be unnecessary/avoided), etc. |
Hi David, I finally had time to get back to this and spend a few hours to root cause why some PointerUnions can't be pretty printed.
It was unrelated to std::__u::pair. The issue is that the PointerUnionUIntTraits may be invisible to the current GDB block if it's only been instanced in a different translation unit.
I've added a test case to show the issue.
I think I asked this elsewhere, but not sure there was an answer (apologies if I forgot - might be worth a comment) - what is this error case for? Are there types in LLVM that don't provide this expected nested type?
Might be nice if it could be removed & then wouldn't need the factory layer of indirection for PointerIntPair and PointerUnion below.