The QObject::connect content assistant does not work when the receiver
of the function call is an implicit this. E.g.,
class Q : public QObject { Q_OBJECT
f()
{
this->connect( ... ); // works
connect( ... ); // does not work
QObject::connect( ... ) // does not work
}
};
I've changed the Qt's ASTUtil.getReceiverType to navigate to the
ICPPClassType through the IScope's. The previous implementation was
relying on the connect function call being an IASTField
I've also added a test case for this problem.
Change-Id: I96c29a9a452280068bda39a63414c50008bfad37
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20399
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
This implements a Codan checker for QObject::connect and disconnect
function calls. There are several overloads for each function, but the
basic call looks like:
Q * q;
QObject::connect( q, SIGNAL( sign() ), q, SLOT( slot() ) );
This function calls requires that Q have a Qt signal called sign and a
Qt slot called slot, e.g.,
class Q : public QObject
{
Q_OBJECT
Q_SIGNAL void sign();
Q_SLOT void slot();
};
The Qt checker raises a warning if either condition is not true.
It also raises a warning for SIGNAL or SLOT expansions without a
parameter.
Change-Id: If68a5bcdabb3f118801675e46ae926e6a250378a
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20231
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
This adds content assistants for QObject::connect function calls and
Q_PROPERTY expansions.
QObject::connect function calls look like:
QObject::connect(
sender, SIGNAL(someSignalFunction(int),
receiver, SLOT(someSlotFunction(int));
The assistant provides proposals in the SIGNAL and SLOT expansions. The
QObject for the corresponding type is used to create a list of signal or
slot function signatures.
Q_PROPERTY expansions look like:
Q_PROPERTY( type name READ someFunction ... )
[The ... is a list of optional attributes.] The assistant proposes
attribute names that have not yet been added. It also proposals
appropriate values for the attribute.
This patch also adds test cases for this feature.
Change-Id: I0eb25235bb423c1cfcd743075331f90f269afea7
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19721
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
The Qt plugins have been naming internal packages using two different
prefixes:
cdt.qt.internal
cdt.internal.qt
This renames all packages to cdt.internal.qt, which seems to be the
convention for other projects.
I've increased the Qt plugin versions because alot of new API has been
added, especially to the qt.core plugin. I increased the version in the
MANIFEST.MF and pom.xml files.
I've also fixed the MANIFEST.MF files to take CDT out of the plugin
names.
I've also replaced a call to CCorePlugin.log(Exception) with a call to
QtUIPlugin.log (and added the logging functions to QtUIPlugin.
Change-Id: I1e3e7b2a42c2eb79fe33608c14a1abcf013a9f2c
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19698
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
API is located at org.eclipse.cdt.qt.core.index package.
Entry point is QMakeProjectInfoFactory.getForActiveConfigurationIn method
that provides ability to retrieve QMake information (IQMakeInfo interface)
for active project configuration of a specified project.
Also allows to listen on changes of such information.
qmakeEnvProvider extensions allows CDT build-system to provide environment
for QMake runs within their build-system.
Information is gather by parsing output of:
1) qmake -query
2) qmake -E file.pro // only for QMake version 3.0
Change-Id: Iae569bdbc89dc26d60530596b66b5227f36dfae6
Signed-off-by: David Kaspar <dkaspar@blackberry.com>
Reviewed-on: https://git.eclipse.org/r/19082
Reviewed-by: Andrew Eidsness <eclipse@jfront.com>
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tags signal and slot methods when the index is created. Uses these tags
to suggest values inside of SIGNAL and SLOT macro expansions. Enabled
only for projects with the QtNature.
Recognizes QObject::connect function calls and suggests SIGNAL(a) and
SLOT(a) for the 2nd and 4th parameters.
When expanding the SIGNAL and SLOT macros within a call to
QObject::connect, suggests signals and slots based on the type of the
previous parameter.
E.g. in
QObjectA a;
QObjectB b;
QObject::connect( &a, SIGNAL(*), &b, SLOT(**) );
The content assistant will suggest the methods of type QObjectA that
have been marked as signals at *, and the methods of QObjectB that have
been marked as slots at **.
Change-Id: Ia6aaa71724547b0977e322399a500f072004767a
Reviewed-on: https://git.eclipse.org/r/10532
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
The signals, slots, Q_SIGNALS, and Q_SLOTS macros are
used as 'keywords' when developing Qt applications. This
patch adds a semantic highlighter for these keywords in
projects with a qtnature.
Change-Id: I7a5906aa69e6d7dab4ce20a16b425ae177f9bd25
Reviewed-on: https://git.eclipse.org/r/10179
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
