Make use of LookupContext to find the right class.
Task-number: QTCREATORBUG-10348
Change-Id: I7f8ec769ff2239d5123726e562a1bd430f8c4567
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
...it's mostly bloat. We can easily check for the function declarations
in the definitions in the resulting document.
Change-Id: I9022faf97a78ae599825ec891011117d65ea0aa5
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
The order of entries was changed ab52154010.
Task-number: QTCREATORBUG-10888
Change-Id: I50f97396fd0f94e4bbaefb30fae8419e89bd4f4d
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
Reviewed-by: Ulf Hermann <ulf.hermann@digia.com>
* Make test data driven
* Compare with reference files
Change-Id: I0fed8fcd689da17229853afc940e575b6f22babe
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
Replace waiting for signal textChanged().
Change-Id: I40feb7d49310d4aa9fae4ca4256e9ce2d0f2ab4d
Reviewed-by: Robert Loehning <robert.loehning@digia.com>
Replace waiting for signal textChanged().
Change-Id: I0798f0ef2e1162d2a2b09da98e53dd8fc50e0a7a
Reviewed-by: Robert Loehning <robert.loehning@digia.com>
Additionally there is no more a way of creating a Qt Quick application
from an existing qml file.
Change-Id: I5c1e8d26640fa3e1b865b6cc97745d64b51edc75
Reviewed-by: Robert Loehning <robert.loehning@digia.com>
Calling fromLocal8Bit() for literals is wrong, since that depends
ont the user's environment. We use latin1 strings exclusively in Qt.
Change-Id: I0cd0986787ea630425773672d3a892fbd0f0a77a
Reviewed-by: hjk <hjk121@nokiamail.com>
Recent versions of GDB seem to require 'make install' to find their
Python bits. Given that this is not really an option, check the
usual suspects, too.
Change-Id: I5217c0184681d4a86992fe0b8989498843b26cea
Reviewed-by: David Schulz <david.schulz@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
The type reported by LLDB for Qt 4 is actually wrong, but the type is
irrelevant for the dumper itself anyhow.
Change-Id: I33002316fa72cc8501f26dcc3ee08675547841ae
Reviewed-by: hjk <hjk121@nokiamail.com>
The previous workaround for the Qt 4 optimized int,uint,short,ushort
QHashNode wasn't working for the QHashNode dumper itself because of
unknown key type. Instead we first try to find the 'key' child directly,
if that fails we look for it in the second child (which would be the
anonymous union from the optimized hash node, which contains the key).
Also fix the expected type for QHashNode in the optimized case for Qt4
Change-Id: Ib48c2c0afec081ff38cd750c3d515a5e678e9661
Reviewed-by: hjk <hjk121@nokiamail.com>
The GDB case is still wrong, but it the data GDB produces.
Change-Id: I97c656a666b98da2f62b354b5d1c699301d67b23
Reviewed-by: hjk <hjk121@nokiamail.com>
This is now (additionally) on a per-entry level, resulting
in less duplication.
Change-Id: Ia93547396384fe5b421c4b601b52476a23cdfa89
Reviewed-by: hjk <hjk121@nokiamail.com>
Make it work with LLDB, show simple values always directly.
Change-Id: I463ef81183792f85243d679dee69a41db00bed07
Reviewed-by: hjk <hjk121@nokiamail.com>
