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>
We get proper notification when QtCore is loaded now, and we either
got it, or not.
Change-Id: I9485126d9b15b8d859ba440f3ba1623f03527ef8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Makes it clear that this is meant to be immutable and is supposedly
faster.
Task-number: QTCREATORBUG-17823
Change-Id: Ie5d67b793e0bc4f704981d5161efc12bcc22100a
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Return the typeId instead of triggering a type lookup when accessing the
type name and no TypeData is available.
Change-Id: I4d46d5356d38184d73427e5a65c3986d30520cf9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
QChar lookup doesn't always return the expected type. Get ahead of
this by hardcoding the type data on initialization.
Change-Id: Ie25c27521afeddc3da917242ce64df3901bcc80b
Reviewed-by: hjk <hjk@qt.io>
