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

Hi Jan and Xaver,

Semantic depends on the major-mode in the buffer, and happens to 
distinguish between C++ and C regarding the includes paths, which we 
query from gcc when possible.

If you work in all c++ code all the time, you can easily just update the 
auto-mode-alist, for example:

(add-to-list 'auto-mode-alist '("\\.h\\'" . c++-mode)

and these sorts of things should be resolved.

Semantic will use c++ from .h files in the cases where it knows it is 
being pulled in from a c++ file, but it is limited since you might pull 
it in from  c file later, or in Xaver's case, opening the file 
stand-alone, and clearly the cache is getting in the way later.

I had the same thought that this was a surprising and hard to understand 
problem, but I'm not sure what to do about it.  I edit C and C++ files 
and they both include stdio.h and friends, so I can't assume one or the 
other.  I'm not sure what in Semantic / EDE I could do about it though 
as both those tools are meant to just hang off the existing Emacs 
infrastructure around this stuff.

Eric


On 10/28/2014 11:07 AM, Jan Goh wrote:
> Hmm, that's interesting. I'm not sure if this is impacting my tags, and I have no way to fix it if it is. (It might explain some of the weird behaviour I see sometimes, but there are lots of other possible reasons for weird behaviour, too.)
>
> I'm working on a project that I'm not the architect of that has hundreds of auto-generated files. As it is, I have to hack around Semantic's assumption that I'm going to put files in directories a certain way (it's a visual studio project, and again, I have no control over the layout of the files).
>
> It would be nice to have a few controls to overcome some of these assumptions. I've been programming in C++ for 15 years in the games industry (using  emacs the whole time) and I've never in that whole time seen anyone use anything other than .h for header files.
>
>
> JG
>
> -----Original Message-----
> From: Xaver Gerster [mailto:[email protected]]
> Sent: October-28-14 10:54 AM
> To: Eric M. Ludlam; [email protected]
> Subject: Re: [cedet-semantic] 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
>>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cedet-semantic mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cedet-semantic mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

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