Besides the announced change to QObject guts in a5a859e72 there has been
at least 6e0b5dadc and possibly more, so give up here.
Change-Id: I84201cef9f2a7515f082f4c3310bdc96f7a4216d
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Don't use two lookups for parent types and act on known null pointers.
While the machinery is robust enough to handle the result it's a
needless deviation in regular code path.
Change-Id: I6e50629cf554870a3ffb9f488f654e6ae557e5b3
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
As per suggestion from Pyls, this changes
if not needle in haystack:
to
if needle not in haystack:
Change-Id: I4a482604e13e61ecee9e02935479632419710ff7
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Should help to drill down to individual expensive dumpers.
Change-Id: I983ba075231784f71dd9d5c3bda375a3ee508bf6
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
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>
