[kdevelop/kdevelop] plugins/gdb/printers: Fix QMap pretty-printer with gcc 16's libstdc++
David Faure <[email protected]>
| Newsgroups | gmane.comp.kde.cvs |
|---|---|
| Message-ID | <[email protected]> |
Git commit 2a137503fa9989cf4984575d887858576a61c911 by David Faure.
Committed on 03/08/2026 at 11:22.
Pushed by dfaure into branch 'master'.
Fix QMap pretty-printer with gcc 16's libstdc++
libstdc++ gained a num_children() method for std::map in gcc 16, and we
call it unconditionally. It has a typo which makes it raise NameError,
so all QMap/QMultiMap unittests failed. Catch that and fall back to
stringifying the map, as we did before gcc 16.
That method also counts elements rather than children, i.e. half of what
its children() yields, so it would have printed half the real size. Both
are fixed together upstream (patches sent to gcc-patches), so a
num_children() that runs at all counts children and we can use it as is.
M +11 -2 plugins/gdb/printers/qt.py
https://invent.kde.org/kdevelop/kdevelop/-/commit/2a137503fa9989cf4984575d887858576a61c911
diff --git a/plugins/gdb/printers/qt.py b/plugins/gdb/printers/qt.py
index 3fe5174d30..a15162233a 100644
--- a/plugins/gdb/printers/qt.py
+++ b/plugins/gdb/printers/qt.py
@@ -512,8 +512,17 @@ class QMapPrinter(PrinterBaseType):
return 0
if self._qt6StdMapPrinter:
- if hasattr(self._qt6StdMapPrinter, 'num_children'):
- return self._qt6StdMapPrinter.num_children()
+ stdMapNumChildren = getattr(self._qt6StdMapPrinter, 'num_children', None)
+ if stdMapNumChildren:
+ try:
+ # Counts the key and the value of each element separately, like we do.
+ return int(stdMapNumChildren())
+ except Exception:
+ # gcc 16.1 raises NameError here, its num_children() has a typo, and it
+ # also counts elements rather than children. Both are fixed together
+ # upstream, so one that runs at all counts children. Fall back meanwhile.
+ # https://inbox.sourceware.org/gcc-patches/[email protected]/
+ pass
# HACK: let's try to stringify the map and see if we can extract the size from there
# this is error-prone but faster than a potential O(N) iteration on `children`