[Geany-devel] C++ Symbols problem

[Colomban Wendling]

Le 18/03/2012 10:59, Lex Trotman a écrit :
> Hi Colomban,
> 
> I used both patches all afternoon with no visible problems.  They seem
> to work as advertised.  Will keep using, thanks.

Great then :)  I now have committed the sidebar fixes.

Cheers,
Colomban

> 
> Cheers
> Lex
> 
> On 18 March 2012 08:36, Colomban Wendling <lists.ban at herbesfolles.org> wrote:
>> Le 13/03/2012 01:48, Lex Trotman a écrit :
>>> Hi All,
>>
>> Hey!
>>
>> Here's an initial patch that fixes the issue by better handling of true
>> duplicate tags.  It's not necessarily the better fix for the issue,
>> where maybe having the template type info would be better, but it is
>> more generic since it would handle any duplicate.
>>
>> It's not much tested, but have fun :)
>>
>> Cheers,
>> Colomban
>>
>>
>>>
>>> There is a problem with symbols in some C++ programs which causes some
>>> class members to appear and disappear or move in the sidebar.
>>> Needless to say this is *very* distracting.
>>>
>>> The minimal program to demonstrate this is:
>>>
>>> template<bool b>class problem;
>>>
>>> template<> class problem<false> {
>>> };
>>>
>>> template<> class problem<true> {
>>>       int i_change;
>>> };
>>>
>>>
>>> The member i_change changes each time the symbols pane is updated,
>>> correctly showing as part of the class at line 6, then part of the
>>> class at line 3, then disappearing, then back to the class at line 6
>>> etc.
>>>
>>> In C++ this program has three class names:
>>>
>>> a) at line 1 declaration of problem<bool>
>>> b) at line 3 definition of problem<false>
>>> c) at line 6 definition of problem<true>
>>>
>>> Note that these are distinct classes as if the names include <bool>,
>>> <true> and <false>.
>>>
>>> But neither symbols.c or the tagmanager parser includes the template
>>> parameters in the name, instead showing both of the classes at line 3
>>> and 6 as "problem".
>>>
>>> Discussion with Colomban on IRC indicated that this may be confusing
>>> the symbol update algorithm.  Forcing a complete re-generation of the
>>> symbols did indeed stabilise the sidebar.
>>>
>>> I think that the problem is due to update_tree_tags() identifying the
>>> parent of i_change just by name so it can't tell if line 3 or line 6
>>> (or possibly line 1) is the parent.
>>>
>>> If  i_change is shown in the symbol tree as part of the class at line
>>> 6 then it will be in the parent_tags hash with parent of "problem".
>>> If this is taken as "problem"of line 3 as parent, it will delete it
>>> from the class at line 6 in pass 1 and as i_change is still in the
>>> tags list will add it to the class at line 3 since thats what the
>>> parent_tags hash says is its parent.
>>>
>>> On the next symbol update, since what it thinks is the parent of
>>> i_change (the class at line 3) does not in fact have i_change as a
>>> member, it will be deleted from the tree and the tags list, so it
>>> isn't added again in pass 2.
>>>
>>> On the next symbol update i_change is not in the tree so it isn't in
>>> the parent_tags hash so it is added where the tags list says is the
>>> correct place.
>>>
>>> If the order of the definitions at line 3 and 6 are reversed i_change
>>> just alternates on and off, suggesting that it isn't the first
>>> definition of the symbol "problem" that is the one found.
>>>
>>> At least I think this is the mechanism?
>>>
>>> Other than the hack to re-create the whole table each time, I'm not
>>> sure how to cure it without distinguishing the three class names, and
>>> that means modifying tagmanager/c.c (shudder).
>>>
>>> Cheers
>>> Lex
>>> _______________________________________________
>>> Geany-devel mailing list
>>> Geany-devel at uvena.de
>>> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>>
>>
>> _______________________________________________
>> Geany-devel mailing list
>> Geany-devel at uvena.de
>> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel