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>
The CDT persists an index of source code relationships by processing the
AST produced by the parser. There is an existing extension-point that
allows contributors to create new linkages in this persisted file.
However there is no mechanism allowing contributors to influence the
data that is stored to the file.
This introduces a new extension-point allowing contributors to
participate in processing the AST that is being persisted to the index.
The intent is for this to be used to store data into the contributor's
new Linkage.
There is no change in functionality for existing linkages. A
contributor will soon be added in the Qt plugin.
Change-Id: I845c90cbf7c713e23319e2ed1168eb7d74db5868
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19089
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
This creates a new method in CPPSemantics that will lookup a list of
IBindings from a qualifiedName. E.g., given:
namespace A
{
namespace B
{
int b;
}
}
CPPSemantics.findBindingsByQualifiedName(scope, "A::B::b"); will return
an array with the CPPVariable binding for b.
This commit contains a new test case for various cases that I've thought
about. I had expected that by using the existing lookup functions (in
CPPSemantics) I wouldn't have to think too hard about various matches.
However, the existing functions didn't work quite the way that I
expected.
Change-Id: I8a5aacba4a02d87f71ed4698aa432c3161395a31
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19067
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
The existing PDOMBinding and PDOMName implementations do not allow
references between linkages. This feature is needed so that the new Qt
linkage can reference elements in the C++ linkage. It will also allow
the C++ implementation for extern "C" to be cleaned up (see
PDOM.getCrossLanguageBindings).
Prior to this change, a PDOMBinding held three lists of names. One for
each of declarations, definitions, and references. This change adds a
fourth list for external references. External references are stored as
a linked list of nodes. Each node holds:
- The linkage id.
- A pointer to the next node (or 0 for end-of-list).
- A pointer to the record of first name in the list.
The linkage id is held separately because a PDOMName does not have any
field of it's own for linkage. By grouping elements in this way, we can
reuse most of the existing list-related code.
External references are accessed through a new PDOMIterator class. This
is needed so that we can advance to the next linkage node when we get to
the end of one node's list of names.
This also adds a unit test for the new API.
Change-Id: Ie2b14848db7409905beda0cec752080d5f42eec8
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/18979
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
