I think I understand now. You want to find
where the reference occurs in the IType for the field. Unfortunately, right now
we don’t store that information in the PDOM. I think the thing to
remember is the PDOM is an index. Its job is to map references and declarations
of bindings to where they occur in a file. From there, if more information is
needed, you need to create the DOM objects. This was the general workflow with
the old index architecture as well.
Having said that, it should be possible to
add these relationships. We have the pointer from the field to the type to the
binding for the class. We just need add the pointers in the other direction.
Feel free to send in an enhancement request and we can look at it for 4.0. As
always, we need to analyze the affects of adding this in to make sure we remain
compatible for the DOM interfaces (which may need to change to add this) and to
ensure the PDOM database doesn’t get too big.
Hope this helps (finally J).
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Neeraj U Bhope
Sent: Wednesday, September 06,
2006 1:04 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] Finding
references using PDOM and then finding the AST elements that contain the
reference..
And probably in more concise words what I really really
want is to walk the PDOM upwards from a given PDOMName.
--
neeraj
cdt-dev-bounces@xxxxxxxxxxx
wrote on 09/06/2006 10:24:03 PM:
>
> > can you not use
IASTName.resolveBinding (PDOMName is an IASTName)
> > to get the IBinding?
>
> Ok I think I was not very articulate the
first time over..and maybe
> am not even now :)..but let me elaborate with
the example that I gave first..
>
> We have
> class A {};
> class B {
> A myA;
> };
>
> If I search for the references of A, I will
get a PDOMName. If I
> call IASTName.resolveBinding() on this I get
the binding for class A
> which is an instance of PDOMCPPClassType. I
do not get the
> PDOMCPPField binding that uses A. If I search
for myA and call
> IASTName.resolveBinding() I will get a
PDOMCPPField. So what I
> wanted is to search for references of A and
then somehow get to the
> PDOMCPPField associated with myA and then
from there to get its
> owner i.e the PDOMCPPClassType instance for
the class B.
> --
> neeraj
>
> >
> > (ICPPField) PDOMCPPField and (ICPPBase)
PDOMCPPBase are both
> IBinding subtypes
> >
> > thanks,
> > Andrew
> >
> > > Oks..maybe not exactly the AST per
se...I saw in the code that when
> > > we add IASTNames to the PDOM we add
stuff like PDOMCPPField,
> > > PDOMCPPBase etc...if there is a way
of getting to these from the
> > > PDOMName that is returned as the
reference it would be good enough
> > > for me so that I save on recreating
the AST and walking over it.
> > > --
> > > neeraj
> > >
> > > cdt-dev-bounces@xxxxxxxxxxx wrote
on 09/06/2006 01:51:04 AM:
> > >
> > > > The PDOM does not store the
AST. It only contains IASTNames and
> > > > IBindings and ITypes. You
would need to recreate the AST for the
> > > > file and walk it to find the
right name given the file location
> > > > stored in the PDOMName.
> > > >
> > > > Doug Schaefer
> > > > QNX Software Systems
> > > > Eclipse CDT Project Lead
> > > > http://cdtdoug.blogspot.com
> >
> > Don't miss out on your chance to...Do
more with Symbian.
> > Make sure you visit the Symbian
Smartphone Show, 17-18 October
> > 2006, Excel, London
> >
> >
> > www.symbiansmartphoneshow.com
> >
> >
> >
> >
*******************************************************************
> > *** Symbian Software Ltd is a company
registered in England
and
> > Wales with registered number
4190020 and registered office at 2-6
> > Boundary Row, Southwark, London, SE1
8HP, UK.
This message is
> > intended only for use by the named
addressee and may contain
> > privileged and/or confidential
information. If you are not the
> > named addressee you should not
disseminate, copy or take any action
> > in reliance on it. If you have received
this message in error
> > please notify postmaster@xxxxxxxxxxx and
delete the message and any
> > attachments accompanying it immediately.
Neither Symbian nor any of
> > its Affiliates accepts liability for any
corruption, interception,
> > amendment, tampering or viruses
occurring to this message in
> > transit or for any message sent by its
employees which is not in
> > compliance with Symbian corporate
policy. *************************
> >
*********************************************
> >
_______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> >
https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
