Non default declaration search mechanism

[Milian Wolff]

On Sunday 22 January 2012 16:03:25 Kucharski, Lukasz wrote:
> 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 why are the enum types unnamed? They *do* have a name after all! Or what 
am I missing here?

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

No idea, please look at the sources for that.

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