Re: semantic-ia-fast-jump 'switches' from gcc headers to local headers

Hi Eric,

I'm sorry for stubbornly getting back to this issue - it persists - and 
I very much hope you are still willing to take a look into this next level:

i) I now have a simple test case, for which this issue pops up 
reproducibly (for me).

This test case respects David's concern about 'bad practice', though 
that does not help.
I am not claiming that this test case is actually the way in which the 
issue is generated in a 'real life' project (after 20min. of work I 
can't possibly reproduce all activities before the issue sets in 
unambiguously), but it has the same 'look & feel'

ii) in that test case your suggestion of flushing the buffer does not help.

A) The test case: Automake project, just one top-level-directory, one 
target, two files: tes.cc, utility.h

------- utility.h -------------
#ifndef _GLIBCXX_IOSTREAM
#include <iostream>
#endif
#ifndef _GLIBCXX_VECTOR
#include <vector>
#endif
#ifndef _GLIBCXX_ITERATOR
#include <iterator>
#endif

-------- tes.cc ---------------
#include "utility.h"
using namespace std;

int main() {
   vector<double> v(10,3.14);
   copy(v.begin(),v.end(),ostream_iterator<double>(cout," "));
   cout << endl;
   return 0;
}


B) Steps to get semantic stuck:

- set up the project and files, compile, shut down emacs
- restart emacs (single pane / single window)
- open tes.cc
- set cursor on 'vector' in declaration on 1st line after 'int main..'
- C-j
- stl_vector.h pops up showing the class vector's definition

So far so good. That is kind of what I expected. Now

- C-x b back from stl_vector.h to buffer tes.cc
- C-x f open file utility.h
- set cursor on 'vector' in '#include<vector>'
- for no particular reason do C-j on that.
   I have the impression that this is where things start to go wrong.
- The preceding C-j does not jump me anywhere, but only
   to the start of the line #include<vector>
- C-x f reopen (or switch back) to file tes.cc
- set cursor on 'vector' in declaration on 1st line after 'int main..'
- do C-j
- *!!* in contrast to the previous action of C-j in tes.cc, now,
   stl_vector.h does *not* pop up anymore, rather utility.h shows up

After that point, semantic seems to have 'forgotten' about the system's 
stl_vector.h, as I described in my original post.

Next I tried your suggestion of
 > M-x semanticdb-typecache-complete-flush RET

- C-x f reopen (or switch back) to file tes.cc
- M-x semanticdb-typecache-complete-flush RET
- set cursor on 'vector' in declaration on 1st line after 'int main..'
- C-j
- *!!* again I get transfered to utility.h rather than stl_vector.h

So it seems as if semantic is completely stuck. Obviously one can shut 
down emacs, restart, and play it again.

Can you reproduce this and if so would you have an idea how fix it?

Xaver


PS.: I've switched from emacs 24.3 to a fresh compile of emacs 24.4 
yesterday, just to make sure ... no change

PPS.: Even if your suggestion of flushing the buffer might be a 
workaround in other cases, for me it turns out not to be too practical: 
reparsing everything can put my CPU and fan into a high-load mode for 
some 20 or more secs.

PPPS.: Just in case there might now be questions like if it is 'good 
practice' to do C-j on header files. For me, it is very natural, since 
every-day header files I write contain tons of template definitions and 
inline code. So, it seems very natural for me to do tag lookup also from 
within header files.




On 10/24/2014 11:53 PM, Eric M. Ludlam wrote:
>
>
> On 10/24/2014 04:18 PM, Xaver Gerster wrote:
>>> Do you think you may need a using statement somewhere to help find
>>> your tag?
>>
>> Hi Eric,
>>
>> I think that 'using namespace std;' statements are all in proper places.
>> A caricature of the structure of the code would be:
>>
>> --------------------
>> // file utility.h
>> #include <vector>
>> using namespace std;
>>
>> ....stuff...
>> [...]
>
>
>> I have not tried if I would get this issue also with a bare bones
>> project stripped down to exactly the preceding caricature. But I'll do.
>>
>>> Good Luck
>> Would you have an additional idea, just to jog that aspect of luck?
>>
>
> Noting that the using namespace was in a header was a good clue.  I
> setup a similar simple file and got the 'correct' vector, commented out
> the using statement, and it still 'worked' by finding the class.  When I
> flushed everything, then it stopped working.  When I put the using
> statement back it correctly, it stayed not working.
>
> I'll guess you might edit something that causes the using to not be
> parsed, then it gets set into a cache that way and it appears magically
> broken for no reason even though the plain-text was long fixed.
>
> I found that:
>
> M-x semanticdb-typecache-complete-flush RET
>
> in the location you are trying to jump from would always correctly 'fix'
> the problem if the text in the headers was correct.
>
> there is supposed to be a system of cross-refs that auto-flush subsets
> of the typecache, but clearly that isn't working out.  That system is a
> bit tricky, so for now, when things misbehave, you can just flush the
> cache.
>
> Eric

------------------------------------------------------------------------------