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

Hi Xaver,

I started putting your example together and the first thing I noticed is 
that utility.h didn't know where vector was.  The reason is that that .h 
files are in C mode, not C++ mode.

When you are in test.c, you are in c++ mode.  When it reaches out to 
'include' utility.h, it forces it to parse in C++ mode because it knows 
that it was included in a c++ file.   While in utility.h and you do a 
jump, it doesn't have that context, so it parses it in C mode, has no 
idea where vector is, and summarily gets lost.  The database cache then 
remembers it couldn't find the header anymore.

I renamed utility.h to utility.hh in both places, and everything seems 
to work swimmingly after that.

If you can't rename the file, stick:

-*- c++ -*-

in your headers and that should fix things up for you.

Eric

On 10/25/2014 08:42 AM, Xaver Gerster wrote:
> 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
>

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