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>
This adds support for Qt slots, signals, and invokables to the QtIndex.
This does not yet generate PDOM references for QObject::connection
function calls and the Content Assistant is not contributed yet.
This also fixes a problem in the GNUCPPSourceParser class (internal to
cdt.core). The class has a protected method that accepts an inner enum
as a parameter. That enum was marked as private, meaning the method
could not actually be used by subclasses. I've updated the enum to
match the visibility of the method.
There are three big areas needed to support Qt methods:
1) Slot and signal regions must be identified in the C++ class
definition. These regions are introduced with special macros and the
region extends to the next region or to the next visibility label.
Single methods can also be marked with (different) special macros.
This only applies outside of a slot/signal region.
I've created QtASTClass which examines the input class spec in order
to identify all such regions. This information is used when creating
the QtPDOM nodes for these methods.
2) Some places in Qt use type information embedded as macro expansion
parameters. The values are lost by the standard C++ parser (since they
are just text in the expansion). I've added an extension to the
GNUCPPSourceParser that accepts an input string (the macro expansion
parameter) and produces an appropriate IASTNode if possible.
3) The Qt moc follows specific and non-standard rules when matching
method signatures inside of QObject::connect function calls. I've added
a utility that creates the same signature using the CDT AST as input.
I learned the rules used by the moc by observing it's output for
significant cases. Those cases have been put into a test case that is
included in this patch.
Change-Id: If812558db315abec637653cc974abf1c0c13d95b
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19672
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
This extends IQObject so that it can return the list of Q_PROPERTY
expansions. Each Q_PROPERTY is represented by the new IQProperty. The
attributes of the property are stored in IQProperty.Attribute.
Where applicable, the attributes insert a reference from the associated
C++ binding. This means that the Q_PROPERTY expansion will be included
in the list of references for the C++ binding.
This also simplifies the process for adding new PDOMBindings to the Qt
linkage. New instances are stored in an implementation of IQtASTName
and able to directly create and return a new QtPDOMBinding. This avoids
creating three parallel inheritance hierachies (compared to the previous
Qt PDOM implementations).
The patch includes test cases to check handling of Q_PROPERTY
expansions.
Change-Id: I7d256d1a938d24a9eb726c472fb150a02f26eb32
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19602
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
handleEvent method updates for related project only
and does not fire listeners under 'sync' lock.
Change-Id: Id9726925ff9c044a3c13238406bdf3228ccf2933
Signed-off-by: David Kaspar <dkaspar@blackberry.com>
Reviewed-on: https://git.eclipse.org/r/19361
Reviewed-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
- Fix AutotoolsNewMakeGenerator.getWinOSType method to
use the build env variables when invoking the sh
command because the path to "sh" may be specified there
Change-Id: Ibcde5de924c50b6557fb4264572ddd59b02bb99a
Reviewed-on: https://git.eclipse.org/r/19400
Tested-by: Hudson CI
Reviewed-by: Jeff Johnston <jjohnstn@redhat.com>
IP-Clean: Jeff Johnston <jjohnstn@redhat.com>
Tested-by: Jeff Johnston <jjohnstn@redhat.com>
The test case in the previous commit was invalid. The test case did not
modify the binding that was referenced by the name and it was checking
for the wrong binding after reading the reference from the Database.
Further, the test case had a hole where the type of binding that was
being used happens to have same node type in both the C and C++
linkages.
I've fixed the test case as follows:
1) The test type is now an enum which has a different nodeType in the C
and C++ linkages. The test case will now be able to catch cases where
the wrong linkage is used when reading the binding.
2) The test case now changes the name to reference a binding in a
different linkage. This means the later code (in the test case) is
expected to actually load a binding from a different linkage.
3) The test case now checks that the loaded binding really did come from
the other linkage. The previous implementation of the test case was
using the wrong binding for the checks.
I've also updated the implementation so that the updated test case
passes.
As an aside, during this update we (Doug and I) noticed that PDOMNames
unnecessarily store a PDOMLinkage. Bindings come from languages, and
therefore need a PDOMLinkage (so that the proper type can be loaded).
Names reference bindings and therefore should not have a linkage. The
motivating example is that there should be one binding for the printf
function, but it could be referenced using names that are created by
different parsers. This can be fixed in a later change.
The major change to implementation is that PDOMNode now stores an
identifier for the factory to use when loading the node. PDOMNode was
already using an int to store the nodeType. I've split this to store
the factoryId as a short and the nodeType as a short. The highest
nodeType currently in use is 58 -- a short should provide ample room for
expansion.
Since PDOMNode is now able to pick the proper factory for loading, we no
longer need the PDOMLinkage.getNode(long) method and I've marked it
deprecated. Instead there is a new method PDOMNode.load(PDOM, long).
Nodes read their factoryId from the database, so the PDOMLinkage is not
needed.
Later commits should cleanup the following:
a) Remove PDOMLinkage from PDOMNode (and related)
b) Change return type of PDOMNode.getNodeType to short
c) Replace deprecated calls to PDOMLinkage.getNode
Among these changes, (a) should allow removal of the external references
list. If names can be loaded without a linkage, then there would be no
reason to store the linkage when storing the name.
Change-Id: Ife2b21cb21ed1ac6d6c361d0ffb8c7434832c79c
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19377
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
This replaces the QtQuick2 project wizard with Qt4 and Qt5 wizards that
include the old content as well as:
1) Make targets to build and clean the project
2) Sample interaction between C++ and QML
3) A Qt header path provider so that paths from the Qt installation are
properly resolved in the project.
Item 3 is particularly important for using the 'New Class' wizard with
QObject as the base class. Unless the Qt paths are pre-populated the
QObject base class will not be found and the New Class wizard's Finish
button will be disabled.
The Qt headers are resolved by running `qmake -query QT_INSTALL_HEADERS`
and then creating IncludePath entries for all sub-folders. This list of
include paths is persisted with other shared language settings into a
file in the workspace metadata area.
The persisted data is reloaded when any of the following change:
- the modification time of the qmake binary
- the modification time of the reported QT_INSTALL_HEADERS folder
The persisted node is ignored when the target qmake binary no longer
exists. The node is removed from the persisted form the next time that
the shared settings are persisted.
Change-Id: Ic82fdb147e6a69060f93e2e9aed2e919139a0ae9
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/16909
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
Qt allows string-based key/value pairs to be inserted into QObject class
definitions. E.g.,
class Q : public QObject
{
Q_OBJECT
Q_CLASSINFO( "key1", "value1" )
};
The class info is accessible in the meta-object system. See:
http://qt-project.org/doc/qt-4.8/qmetaclassinfo.html
For more information.
This patch adds the API to access these key/value pairs from the
QtIndex. The values are stored in a single block in the PDOM record for
the QObject.
The API returns the value for a given key if it is found in the receiver
QObject or any of its base classes. The API returns the first such
value that is found.
This patch also adds a test case for this functionality.
Change-Id: Ie3f821a0c5f6f1347a0c0c6dafa184510ae26c29
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19154
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
