When the language settings providers functionality is enabled, also
check for build settings customization, not just the language setting
entries.
Change-Id: Ia9fec3bc377617dc9f2264dd924941879f1b64b0
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/20297
Tested-by: Hudson CI
Reviewed-by: Andrew Gvozdev <angvoz.dev@gmail.com>
IP-Clean: Andrew Gvozdev <angvoz.dev@gmail.com>
Tested-by: Andrew Gvozdev <angvoz.dev@gmail.com>
This extends the QtIndex to support C++ classes that have been annotated
with the Q_GADGET macro. QGadgets are normal C++ classes that are able
to host Q_ENUMs.
The implementation classes for QObject have been modified to share
common parts with the implementation for QGadget. The types are
intentionally not related in the QtIndex API. This allows for divergent
changes in the Qt spec.
This patch includes new tests cases for Q_GADGET.
Change-Id: I59eb745ff5614c2897d67dd7d6807763091120af
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20236
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
available
Change-Id: Id950622f6ca39639addeedc33e8d1c3fadd611e0
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/20028
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>
