ODP: Non default declaration search mechanism

Sun Jan 22 16:51:39 UTC 2012

Hi Milian,

Enumeration type always have proper name.

I was referring to enumeration context (in c++ this is don in visitEnumSpecifier)
so lets call it enumeration specifier context. This context need to be unnamed
to make findLocalDeclarations and findDeclarations methods work (I mean to find
enumerator declarations inside those context - In my experience
PropagateDeclarations flag set to true doesn't help). 

When I used named enumeration specifier contexts then find... works only when
qualified identifier with context scope id is used - but this complicates things
too much.

When going though implementation of DuContext I found something called Local 
Declarations Hash which currently is disabled (needsLocalDeclarationsHash always
returns false). So in my case when searching enumerator declarations inside
named enumeration specifier context (declaration propagation is enabled)
findLocalDeclarationsInternal methods uses:
PersistentSymbolTable::self().declarations(id, count, declarations);

Search declarations are not found because id passed to declarations method
do not contains name of enumeration specifier context.

Lukasz

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

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