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

Hi Eric,

 > ... reason is that that .h files are in C mode, not C++ mode ...
 > -*- c++ -*- in your headers should fix things up for you ...

Ok. that's it. Working again. Thx.!

While it was an eye-opener to read from you that semantic's action 
depends on the file's extension, i.m.h.o. (obviously very humble), it 
seems awkward though, that uneducated users like me can 'magically' kill 
tag lookup even in properly named files (in my case tes.cc) only because 
there is an improperly named file around (in my case utility.h). It 
would be cool to have some kind of warning for such cases.

Anyway I am warned now.


Xaver




On 10/27/2014 01:47 PM, Eric M. Ludlam wrote:
> 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
>>

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