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>
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>
The Qt meta-object system allows C++ enums to be added as simple enums
and as flags. There is more detail at:
http://qt-project.org/doc/qt-4.8/qobject.html#Q_ENUMS
and http://qt-project.org/doc/qt-4.8/qflags.html
This patch adds IQEnum to the QtIndex. IQEnums are contained in
IQObjects and therefore are accessed with the IQObject.getEnums.
An IQEnum holds its name, enumerators, and a boolean indicating whether
the instance represents a Qt flag.
A Qt flag is an enum where the enumerators are intended to be used with
bitwise operations. The Q_DECLARE_FLAGS macro is used to introduce a
type-safe container for the flags.
This patch also adds unit tests for this new functionality.
Change-Id: If51524e93533bae82a3263f3c7973a31793a8a83
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19147
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
This uses the new PDOMASTProcessor extension point to create a
Qt-specifc PDOMLinkage. This initial version of the linkage only stores
QObjects and their base classes. Later commits will fill out other
details and introduce classes that use this data for things like Content
Assistance and Codan checking.
This patch introduces the following:
1) QtIndex: This is an index that provides access to Qt-specific data.
The index is mostly a wrapper on the CDT's existing IIndex, but it
provides very specific information about the Qt elements. The only data
that can be accessed from the QtIndex (in this patch) is a QObject and
the QObject's that appear in its base class specifier list.
2) QtPDOMLinkage: This linkage is implemenated as an extension of the
PDOMCPPLinkage. In some cases it adds references to Qt names from the
C++ bindings.
3) Test suite: The test suite has some base classes for parsing the Qt
source code. The only test case is for the simple functionality that is
being added in this patch -- examining the base class specifier list of
QObjects.
These areas will be extended in later patches.
Change-Id: I13fb83beb7f50cd2efb1de97b562245dc642468d
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19113
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>
Qt allows signals and slots to be marked directly on the function, e.g.,
class T
{
Q_SIGNAL void some_signal();
Q_SLOT void some_slot();
};
This change modifies the Qt signal/slot tagger to look for these tags in
addition to the previously implemented search for the visibility label.
Change-Id: Ibf43df8d80d4ca9f8b62776e7a35a4fc067a289e
Reviewed-on: https://git.eclipse.org/r/10701
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
Addresses review comments from https://git.eclipse.org/r/#/c/10648.
Fixes the junit problems by making sure that the dummy PDOM acquires its
write lock before calling exercising the tag index.
Original commit message:
This new extension point allows contributors to put their own
information into the PDOM and to later retrieve it for their own
purposes.
There are many details in the bug. The idea is that contributors
provide an implementation of IBindingTagger, which is given a chance to
examine IBindings when they are created. The ITagWriter interface
allows the contributor to create a new tag which can then have data
written to it.
The ITagService interface (accessible from CCorePlugin.getTagService()
provides a way for the contributor to later get an instance of
ITagReader to retrieve tags from bindings.
ITags are copied to the PDOM when the associated binding is persisteed.
Contributors use a unique id (based on their plugin id), so that
multiple contributors are able to independently tag a given binding.
In-memory tags are not cached. I've done some timing tests using my
sample implementation and found no measurable difference. The full log
lines look like:
!MESSAGE Indexed 'simple-01' (2 sources, 184 headers) in <see below>
sec: 21,550 declarations; 35,394 references; 0 unresolved inclusions; 1
syntax errors; 0 unresolved names (0.00%)
I did 5 tests using the current master (no tagging-related code), the
times were:
18.86 sec
9.17 sec
5.91 sec
4.79 sec
4.83 sec
And then I ran the same sequence of tests using the code in this
commit:
18.73 sec
9.39 sec
6.50 sec
4.78 sec
5.27 sec
If performance does become a problem, then caching could be introduced
with a new implementation of ITaggableService. The two problems are
finding a key other than the identity of the IBinding (since IBindings
are re-created often) and properly evicting stale entries when the
binding is no longer valid.
The process of copying tags from an in-memory IBinding to a PDOMBinding,
is a synchronization. This means that tags that are no longer
applicable, will be removed from the persistent store.
While developing this I found that PDOMBindings are not deleted from the
Database (only the names that reference them are deleted), so there is
no provision for deleting all tags at once.
New database locks are not needed. By the time the persistent tags are
accessed, higher levels of code have already taken a read or write lock
as appropriate.
There are new unit tests covering the changes to the PDOM.
Change-Id: I6ae1afc949082f7f4484b3faa1550670be43312f
Reviewed-on: https://git.eclipse.org/r/10659
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: 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>
