There's no need to go through unknown enum sizes here, they are known.
Also, make it work for namespaced Qt. Avoid casts to typedefs.
Change-Id: I9c6fc44a03a0c245f05957306a129f6902f8cf85
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Prioritize displaying as enum if a type is known
to be an enum. Otherwise this would just end up
get displayed as string representation of its value.
Enable respective dumper tests.
Change-Id: I3e5406e14a68f02741b6144bb54528b72cc8192d
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: hjk <hjk@qt.io>
The dumper calls PyObject_Repr and shows the result of that as the
value of a PyObject.
It also adds three new sub fields to show the object class (type),
super class (base class), and the meta type (the type of the class
object).
Change-Id: I0612833321f6d2b50826588e775cfa12e1db28e4
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Mostly for sanity reasons when debugging the QObject dumper itself.
Change-Id: I7d6267625f091788e73b0b28695e9b99e33ab3e3
Reviewed-by: David Schulz <david.schulz@qt.io>
When used in SubItem, enums were displayed as
"value of type E at address <addr>".
Change-Id: Ieecfb791126c6f63f272817afc6c8d05f28b9242
Reviewed-by: David Schulz <david.schulz@qt.io>
Qt Creator failed to properly display GDB's LazyString.
The problem was that GDB's 'PlainDumper::__call__' passed a 'gdb.Type',
while 'DumperBase::putCharArrayHelper' called methods that are only
defined for the custom and more abstract 'Type' type defined in 'dumper.py'.
As described at [1], GDB's 'LazyString.type' "holds the type that is
represented by the lazy string’s type. For a lazy string this is a pointer
or array type. To resolve this to the lazy string’s character type,
use the type’s target method."
In addition, 'gdb.Type' does not have a 'size()' method, just a 'sizeof'
member, s. [2].
Since all other uses of 'DumperBase::putCharArrayHelper' are passed
a "proper" type, extract the code common to the GDB case and all others
into a separate method and directly call this one for the GDB LazyString
case.
[1] https://sourceware.org/gdb/onlinedocs/gdb/Lazy-Strings-In-Python.html#Lazy-Strings-In-Python
[2] https://sourceware.org/gdb/onlinedocs/gdb/Types-In-Python.html#Types-In-Python
Task-number: QTCREATORBUG-20939
Change-Id: I16608668c9403b6d8e509dab17eb1788586f453e
Reviewed-by: hjk <hjk@qt.io>
Make the hex display work with LLDB, fix GDB and LLDB test.
Change-Id: I529b5cdc908dbcba7270bc4574fa59a012fcacad
Reviewed-by: David Schulz <david.schulz@qt.io>
This function is available only for GDB. When using CDB or LLDB
this ends up in an exception.
Change-Id: Ie1835c1b95cac99e3f996077f6a3d80b5591c145
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Only needed for native combined debugging.
Task-number: QTCREATORBUG-18577
Change-Id: I7c5d877b9601e77ab8de251305db829a07675f8d
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It's a lot more useful to see in Qt Creator:
QAbstractFileEngine::FlagsMask (0xff00000)
Than
QAbstractFileEngine::FlagsMask (267386880)
Change-Id: I8d96dea9955d4c749b99fffd14cd690574b433e5
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
This also fixes accessing 'this' when located inside a
different thread.
Task-number: QTCREATORBUG-18466
Change-Id: Ib90cc23c65c033a234d3f7cf9b1ba76abff719e2
Reviewed-by: hjk <hjk@qt.io>
Parsing has to stop at the first < (coming from the end).
foo::span<int>::bar<double> has a parameter 'double', not 'intdouble'.
Change-Id: Ied142d5e75a7587d6c0efd3b51608b199b999e93
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
int main()
{
int foo = 42;
void *bar = &foo; // bar has no object address
return 0;
}
Change-Id: I917c2976bd618c096bfd704abff8b3538e38a0d3
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This requires making template argument extraction a bit more robust
GCC 5.4.1 created debug info only reports the first argument for
boost::variant<int, bool>:
#include <boost/variant/variant.hpp
int main() { boost::variant<int, float> v = 1; return 0; }
py print(gdb.parse_and_eval('v').type)
-> boost::variant<int, float>
py print(gdb.parse_and_eval('v').type.template_argument(0))
-> int
py print(gdb.parse_and_eval('v').type.template_argument(1))
-> Traceback (most recent call last):
File \"<string>\", line 1, in <module>
RuntimeError: No argument 1 in template.
Error while executing Python code.
Change-Id: Iedca8b073078c93449ab61bb2cab05d6cd9803ba
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It's used twice, always for 'this', and whenever asked for by the
user's 'Dereference Pointers Automatically' choice, but needs to
be done at different times.
Change-Id: I4dc7340d0a4cb3eb0c7ff17d59e39be0e3870aa0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Gcc does not write out full type names with 'using template ...', see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80466
This is in most cases harmless for Creator as dumpers are triggered
independently of template arguments. However, if the dumper takes
different code path based on the template argument type, as is
e.g. needed for std::vector<bool>, wrong results are produced,
as the type cache only used the template base name as type id.
Work around by mangling the id of the un-typedef-ed type into
the type id of a typedef, which, in case of templates contain
the full parameter list.
Change-Id: I63c59cccdc186b09ff780e9dfd57b0ad668ae98f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Throwing an exception in these cases is not uncommon and should
be handled properly.
Change-Id: I8d4377bf26a4e31971da724904dd5ea5f01a95e1
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
