Non default declaration search mechanism

Sun Jan 22 15:03:25 UTC 2012

Hi Milian,

Thanks for all tips.

In the meanwhile I've checked value returned by indexForUsedDeclaration method depending on passed declaration and for enumerator declarations with same name but in different enumeration types give the same declaration index (case - enumeration types with unnamed context).
But when setting setAlwaysForceDirect to true indexForUsedDeclaration start to works as expected and gives different declarations indexes for different enumerators.
What you know about memory and computational complexity of AlwaysForceDirect?

Lukasz

-----Wiadomość oryginalna-----
Od: ext Milian Wolff [mailto:mail at milianw.de]
Wysłano: N 2012-01-22 15:14
Do: Kucharski, Lukasz (NSN - PL/Wroclaw)
DW: kdevelop-devel at barney.cs.uni-potsdam.de
Temat: Re: ODP: Non default declaration search mechanism

On Sunday 22 January 2012 03:25:40 Kucharski, Lukasz wrote:
> Hi Milian,
> 
> Yes, I'm doing it openly, currently sources are available here:
> http://gitorious.org/kdevttcnsupport. I will consider to move this project
> to KDE git.
> 
> 
> When building enumeration types with unnamed context, I was able to get two
> instances of enumerator declaration, it was possible to distinguish
> enumeration type but next step seems to be problem. No matter which
> declaration is passed to newUse method effect is always the same, most
> probably due to same qualifiedIdentifier.
> 
> So how to overcome this issue?

First up, your UseBuilder::buildUses(AST * node) looks overcomplicated and 
esp. the call to setRecompiling(true); might be hazardous. Take a look at the 
PHP plugin, that does this imo quite cleanly and should give a good idea to 
you.

Then to newUse: It should take the declaration you pass it to, and should 
*not* be based on the qid. I'm pretty sure this works as expected, so I think 
you should try to add some more debug output or such to your code to verify 
that the correct declaration is passed along. Otherwise please write a small 
unit tests that shows the behavior and I might be able to look into it.

PS: storing raw pointers to Declaration or DUContext, then unlocking the 
duchain and relocking it again later on and then trying to access the raw 
poiters is not a good idea. Use the smartpointer classes like 
DeclarationPointer to verify that the declaration is still valid. After all, 
when you unlock the chain, some other thread might have deleted the 
declaration.

PS: // doxygen dosn't say anything about locking duchain before 
findDeclarations
-> that's wrong then, the chain is definitely required to be locked when 
calling this.

PS: you should add proper licenses to your files, please take a look at:
http://techbase.kde.org/Policies/Licensing_Policy

> -----Wiadomość oryginalna-----
> Od: ext Milian Wolff [mailto:mail at milianw.de]
> Wysłano: N 2012-01-22 03:03
> Do: kdevelop-devel at barney.cs.uni-potsdam.de
> DW: Kucharski, Lukasz (NSN - PL/Wroclaw)
> Temat: Re: Non default declaration search mechanism
> 
> On Sunday 22 January 2012 02:36:47 Kucharski, Lukasz wrote:
> > Hi all,
> > 
> > I am currently working on a ttcn3 plug-in for kdevelop and I've
> > encountered
> > a problem that I don't how to solve in elegant and efficient way.
> 
> Hey there!
> 
> Cool to see more people working on KDev plugins. Are you doing this openly?
> If not, please do so! Put your code up on git.kde.org, should make it
> easier for you and all others to use it.
> 
> > Following C/C++ represents my problem:
> > 
> > enum AAA
> > {
> > 
> >     one,
> >     two
> > 
> > };
> > 
> > enum BBB
> > {
> > 
> >     one,
> >     two
> > 
> > };
> > 
> > const AAA c_val1 = one;
> > const BBB c_val2 = one;
> > 
> > Of course this won't compile however equivalent ttcn3 code is valid.
> > 
> > Having 'one' enumerator in two different enumeration types requires named
> > context to allow use definition to valid enumerator.
> > 
> > Enumeration types without named context allows to find all 'one'
> > declarations but use chain is build always to first declaration, I mean
> > declaration from AAA type. Enumeration types with named context
> > [setPropagateDeclarations(true)] do not allow to find enumerator
> > declarations with default search mechanism. I were able to successfully
> > overload findLocalDeclarationsInternal and findDeclarationsInternal
> > methods
> > to achieve required functionality however it's very slow.
> 
> Personally, I would do it even differently. That is, (maybe) use
> propagateDeclarations, but definitely don't overload the findDeclarations*
> methods - that's pure suicide (as proven by looking at the actual
> implementation / the c++ overload).
> 
> Couldn't you maybe achieve the above by manually checking the following
> conditions in your usebuilder and handle them appropriatly?
> 
> - if inside assignment expression
> - if target-type is of type enum
> -> look for declaration in enum-declaration's internalContext
> 
> This might work for this case, but I'm not sure about your language's other
> features. Does it allow function-overloading?
> 
> foo(AAA) {...}
> foo(BBB) {...}
> 
> foo(one); <-- which one is called?
> 
> > Is there anybody there that knows declaration search mechanism well enough
> > to point me a right direction?
> 
> Personally I found it much simpler (in most of my C++ work and in all of my
> PHP work) to just use the plain old findDeclaration* functions just within
> the proper context.
> 
> Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de