Symbol completion for inlined static fct.s ?

[hs2]

@Dennis: One more problem:
When the 'Defs TB' is active the Tagprops TB correctly checks 'static' for a 'static' fct.
When the Symbol TB is used/active instead 'static' it's NOT (maybe never ?) checked for exactly the same fct.

HS2

[hs2]

@Dennis: Concering my initial issue it's getting really weird.
If I add the '#define static' to the CPP setup, the workspace is retagged and list-symbols works fine (shows the static fct.).
If I remove it again, workspace is retagged BUT list-symbols STILL works fine !?
If I add/remove one more completely unrelated and senseless CPP #defines, list-symbols keeps displaying the symbol. Great - it works !!!
Now I'm exiting SE and restart it.
Guess what - list-symbols is still displaying the static fct. Great - it REALLY works !!!

But ... if I add another CPP define now and workspace is retagged - list-symbols is not longer showing the static fct.
That's the reason why it SEEMED to work last time - oh no !

Seems that there is a really nasty (caching ?) problem somewhere else besides my tiny 'static'-issue which can be worked around.
I hope you can derive sth. useful from my spam-postings to find it.

Good luck,
HS2

Edit: I've checked 'restore symbol browser tree' which could be somehow related.

[Dennis]

Wow.  I'll try to help as best I can.

1) yes, you will need to #define __inline__. The tagging engine will not recognize that.  I'm not even going to ask what is the difference between __inline__ and regular inline.

2) If the tag file is up-to-date, generally, the tag properties you see when you start from the Defs or the Symbols tool window should be the same.

There is one exception to (2).  Inconsistent use of modifiers in code.  This is something I really which C++ had never allowed -- If I had written the compiler, this would be an error, and you would get a small electrical shock whenever you tried to compile it.

Code: [Select]

   int myLittleFunction(const char *);
   ...
   inline int myLittleFunction(const char *s) {
      // why +1, no one will ever know
      return strlen(s)+1;
   }

The Defs tool window is very exact about what it displays, so it will show the function as inline and the prototype as NOT inline.

The Symbols tool window shows what is in the tag database.  And the database tries to be smart in order to patch up the inconsistencies.  So, when it sees that the function is inline and the prototype is not inline, it will try to propagate the inline flag out to the matching prototype.  Generally this works, but if you are seeing inconsistent behavior, this could be the problem.  It does this for static, inline, and private and protected flags.  However, if it is impossible for the simplistic (fast) lookup to match the prototype to function to propagate flags, the flags will not get propagated.  I do not know if this is the problem you are seeing or not, but maybe this explanation helps some.

[hs2]

@Dennis:
1.) Oh dear - it's also a nightmare (along with abusing the preprocessor as 'programming language').
Of course there is no difference. __inline__ is a gcc builtin, inline is standard and unfortunately both are used in existiing (3rd party) SW.
I wouldn't even consider to use __inline__ or __asm__ b/c I always try to stick to the standard wherever possible.

2.) In my case there is just a header file containing both prototype and definition.  It's one of these 'static inline fct () {}'.
I also tried the standard conform notation to exclude any interference with '#define __inline__ inline'. Same result.

But maybe the inconsistency of Defs vs. Symbols TB is caused by the same problem that makes 'list-symbols' fail in the really strange way I tried to explain.
I'm a bit concerned about it b/c it decreases my confidence level to the tagging DB/engine.
Can you explain what's going on there or do you need any further details about it (although I tried to post quite comprehensive) ?

HS2

[hs2]

@Dennis: Some final findings:

0. using the '#define static static' workaround in the CPP setup
 -> the static attribute is not checked in tagprops being consistent regardless which TB is shown
 -> list-symbols lists the static inline fct. when used in cpp file

1. I remove the '#define static static' workaround from CPP setup -> tagfile is rebuilt
 -> tagprops are ok when Defs TB is shown (static is checked)
 -> using Symbols TB tagprops are inconsistent (static is unchecked)
 -> list-symbols still shows the static inline fct. when used in cpp file
 -> switching workspaces doesn't change anything
 -> manually rebuilding the tagfile doesn't change anything
 -> manually retagging all sources doesn't change anything

2. exit SE and restart
 -> tagprops are ok when Defs TB is shown (static is checked)
 -> using Symbols TB tagprops are inconsistent (static is unchecked)
 -> list-symbols still shows the fct. when used in cpp file
 -> switching workspaces doesn't change anything
 -> manually rebuilding the tagfile doesn't change anything
 but:   
 -> manually retagging all sources NOW works as expected
 ---> the static attribute is checked in tagprops being consistent regardless which TB is shown
 ---> but list-symbols doesn't list the static inline fct. when used in cpp file

3. re-adding the '#define static static' workaround to CPP setup -> tagfile is rebuilt
 -> the static attribute is not checked in tagprops being consistent regardless which TB is shown
 -> list-symbols lists the static inline fct. when used in cpp file

Conclusion:
The hotfix I got from support didn't fix the list-symbol issue for static inline functions defined in a header file and used in a cpp file and without the '#define static static' in the CPP setup.
It's strange that 3.) gives consistent results immediately after the tagfile is rebuilt but 2.) not.

However, there is definitely a consistency problem of the tagging DB considering 1.) -> 2.)

I think that needs to be fixed in v12.03 b/c it may lead to some really strange effects.
I hope it helps and all the time spent wasn't for nothing

HS2

[hs2]

@Dennis: Regarding some ofl these '__<keywords>__' I found this explanation in the GCC manual.

5.40 Alternate Keywords

-ansi and the various -std options disable certain keywords. This causes trouble when you want to use GNU C extensions, or a general-purpose header file that should be usable by all programs, including ISO C programs. The keywords asm, typeof and inline are not available in programs compiled with -ansi or -std (although inline can be used in a program compiled with -std=c99). The ISO C99 keyword restrict is only available when -std=gnu99 (which will eventually be the default) or -std=c99 (or the equivalent -std=iso9899:1999) is used.

The way to solve these problems is to put `__' at the beginning and end of each problematical keyword. For example, use __asm__ instead of asm, and __inline__ instead of inline.

Other C compilers won't accept these alternative keywords; if you want to compile with another compiler, you can define the alternate keywords as macros to replace them with the customary keywords. It looks like this:

     #ifndef __GNUC__
     #define __asm__ asm
     #endif

-pedantic and other options cause warnings for many GNU C extensions. You can prevent such warnings within one expression by writing __extension__ before the expression. __extension__ has no effect aside from this.

Just FYI,
HS2

BTW: Any news regarding my prev. posting ? I'd just like to know if I do sth. wrong or if it's a confirmed issue. Thanks !

[hs2]

v12.03 still shows exactly the same behaviour as described for v12.02. Any news / information about that ?
HS2