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>
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 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>
