This makes the use of '@' prefixes in split('{@QString}'...) etc
mandatory, thereby removing the guessing on whether namespaces apply
or not on the dumper 'core' side, and removes the guessing on
whether dropping the '@' 'works' on the individual dumper implementation
side.
Amends 1074c2ffce.
Change-Id: I44611eb09557638dec12d2e2f78cdaeac0bbd449
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This makes meta method and property names visible again.
Task-number: QTCREATORBUG-24098
Change-Id: I2e0522396a5e91be43ae6b850217b9153b29a962
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Also rename it to vectorData, in line with byteArrayData and stringData
Change-Id: I91a4ddba272fcada3e451680ba5a5a756f7a976e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Mainly because it is getting in the way of the string data dumper
consolidation. We can re-enable that afterwards. The loss here is
limited either way as QArrayData is only an implementation detail
of some Qt container, rarely, if ever used by end users.
Change-Id: I7e9074434f84da536d603b6a163a3a039facc8fc
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Essentially removing the parts that are gone in Qt6
Task-number: QTCREATORBUG-24098
Change-Id: I49f7ed8ea8e568803850bd4a0118b690248013af
Reviewed-by: David Schulz <david.schulz@qt.io>
This was incomplete, can conceptionally not be complete, and most
of the sizes were wrong for Qt 6.
Change-Id: Id107b30dd6707b280c18a5d2065a4ec9c39fb035
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It's generic, and operating on QArrayData (-subclasses).
Change-Id: Ieedc0f1e3f573aeeb422eb9516d4634e6e0da4b9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This fixes the QUrl dumper.
Task-number: QTCREATORBUG-24098
Change-Id: I2dbc2f477c33bc0c7337e8a925dd0a35d15aa31f
Reviewed-by: David Schulz <david.schulz@qt.io>
Move the version dependency into the dumper base instead.
This also fixes the QFileInfo display, but not yet QFile.
Change-Id: Ia2cb75b2a74cbbd4bb2d6ede2178d96792883912
Reviewed-by: David Schulz <david.schulz@qt.io>
This is a completely new structure, also effective order when
iterating is completely different.
QHashIterator doesn't work yet.
Task-number: QTCREATORBUG-24098
Change-Id: I917cacf7952d9d54a31d14a0691213ab944d0d8f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Chicken out of the QStringList == QList<QString> in Qt 6 dilemma
by using QList<QString> everywhere, that's not important for the
QMap test. value/key vs first/second nevertheless needs adaptation.
Task-number: QTCREATORBUG-24098
Task-number: QTCREATORBUG-23806
Change-Id: I4bdb8222978de7e7f1596be380e0fedc8f9d1a06
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
... for std::vector and std::string.
Change-Id: I5c823b6c1b7b510344eeea4e1d5db0791d5c8e53
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
In the newest version of LLDB, they remove anonymous and inline
namespaces from their display name, which breaks all debugger helper
code on Macs with the newest version of Xcode, since Qt Creator logic
determines libc++ vs. libstdc++ by the presence of the "__1" inline
namespace.
Change-Id: I139d0654ffbc9dec2e42b40eaad92ea2e3c067c0
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
QVector is a template alias to QList in Qt 6 and gcc creates insufficient
type information for template aliases:
g++ (Ubuntu 9.3.0-10ubuntu2) 9.3.0:
<1><91>: Abbrev Number: 8 (DW_TAG_typedef)
<92> DW_AT_name : QVector
<96> DW_AT_decl_file : 1
<97> DW_AT_decl_line : 5
<98> DW_AT_decl_column : 29
<99> DW_AT_type : <0x2d>
<1><9d>: Abbrev Number:
clang version 10.0.0-4ubuntu1:
<1><86>: Abbrev Number: 8 (DW_TAG_typedef)
<87> DW_AT_type : <0x67>
<8b> DW_AT_name : (indirect string, offset: 0x4a): QVector<int>
<8f> DW_AT_decl_file : 1
<90> DW_AT_decl_line : 5
<1><91>: Abbrev Number: 0
In order to not regress on what the user sees we generate the full
type name for the common case in the dumper.
Task-number: QTCREATORBUG-24098
Change-Id: Ic0b70b1b87ee027fc3fcc0409ea23f56a175bcc3
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
When 'char *' typedefs (and the like) are used, this makes
the actual (i.e. the typedef's) type name shown instead of the
one that the type is a typedef for.
For example, 'gchar' is shown as type for all elements of a 'gchar*'
when expanding that one in the debugger's locals or expressions view.
Original display of text representation for 'char *' typedefs etc.
had been added with commit 70c4889ac9
("Debugger: Show text representation for 'char *' typedefs etc",
2020-06-26). Move the typedef resolution one level down so the
original type name is still available for display.
This also extends the existing 'gchar *' test case accordingly.
Change-Id: I9558360b3bf96906d6dc39a63706bb8ce28c2f1c
Reviewed-by: hjk <hjk@qt.io>
When adding expressions for bitfield members in the
debugger's expression view, their corresponding 'gdb.Value'
does not expose the fact that those are actually bitfields,
so e.g. an 'int : 3' is exposed like a "normal" 'int'.
Previously, this would result in wrong values being
retrieved in the 'DumperBase::Value::integer()' function,
when trying to read the value from the corresponding
memory address.
To avoid this, retrieve the actual int representation
for numeric values from the corresponding native 'gdb.Value',
remember them and return that one, similar to how it
is already done for known bitfield members
(s. 'Dumper::memberFromNativeFieldAndValue').
The conversion from the 'gdb.Value' does not work
for integers of a size larger than 64 bits
(like '__int128' used in the "Int128" dumper test).
Therefore, just ignore conversion failures and don't
remember any value explicitly for those cases,
so the same handling as previously used is applied.
(At a quick glance, the reason seems to be that this
is because GDB's corresponding functions use 'int64'
as a return value of the relevant functions [1] [2],
but I did not look closer into what GDB does
internally.)
Corresponding tests will be added in a separate commit.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdbsupport/common-types.h;h=f5b2f3d249177acea77231c21c5601f959c18d2f;hb=f3034e25fa98d44b775970f40c9ec85eeae096e6#l33
[2] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/python/py-value.c;h=6e29284aad11ff344789152a4f601b3474d86bb5;hb=f3034e25fa98d44b775970f40c9ec85eeae096e6#l1706
Fixes: QTCREATORBUG-24693
Change-Id: Idfc3390115e8796f3c778070c23424c3dbdfeddd
Reviewed-by: hjk <hjk@qt.io>
This avoids creating individual child items when expanding a QString.
Change-Id: I49382dcf947ee7ac0470415a71ab05ede5f71b29
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... to something that works with LLDB 12.
Task-number: QTCREATORBUG-24596
Change-Id: Ib2f8255d45a02fa3d2c737864994397f587e9b15
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Enable the functionality for cdb again.
Change-Id: I75405f830dd208cc110d6682a45beedf2f4199cc
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Changed the dumpermodules list to be dynamically retrieved as all
<module_name>types.py files instead of a hardcoded list. I don't know of
any reason it should be a hardcoded list, and this allows for more than
one custom extra dumper file instead of having to specify one extra one
and/or use personaltypes.py. It seems strictly better.
The code used is confirmed to be compatible with all versions of Python.
Change-Id: Ic1988961d5cb7e6523e84afdd0e6c4ed2993ac97
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Missing call to `.integer()` for the vector's size on the LLDB (libc++)
code path leads to a garbage size value and a failed size check. Fix is
to add the missing call `value["__size_"].integer()`.
Change-Id: If2113514fec02d9de248c1b4d3b0baea4f7ee5d2
Reviewed-by: Jeremy Barenholtz <jeremyephron@gmail.com>
Reviewed-by: hjk <hjk@qt.io>
The lookup for qdump function was done by "struct Foo" instead of just
"Foo".
Change-Id: I325d00910a0c13c5e67692737033531e18392247
Reviewed-by: hjk <hjk@qt.io>
Sample broken output:
>result={token="9",lldbid="1",valid="1",hitcount="0",threadid="0",oneshot="0",
condition="",enabled="1",valid="1",ignorecount="0",locations=[
{locid="1",function="foo()",enabled="1",resolved="0",valid="1",ignorecount="0",
file="F:\Projects\test\main.cpp",line="5",addr="4199979"},],
file="F:\Projects\test\main.cpp",line="5"}@
When parsed as GdbMi value, the strings are expected to be escaped.
Change-Id: Idb923516c1cf6e25b970ad08fae977bdf1045b4b
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It's an int. Still, the position is 3 pointer-sizes back due to padding
(the next member after this struct is the char pointer).
The pointer-size + bitwise stripping of the LSB probably doesn't work
on big-endian archs.
Change-Id: I4413d9b32986d1ea0be9abe1be4382ee36a9456c
Reviewed-by: hjk <hjk@qt.io>
