Re: [CEDET-devel] Pre-release status question

[David E. <de...@ra...>]

"Eric M. Ludlam" <er...@si...> writes:
>>>> Alastair Rankine <ar...@in...> seems to think that:
>>Secondly I am still seeing the problem in the cedet integration tests
>>relating to the constructor in srecode-generated c++ classes. Also
>>reported by someone else, can't remember now.
>>http://thread.gmane.org/gmane.emacs.cedet/3066/focus=3090
>>
>>Again I apologise for not having the time to track either of these down,
>>but just wanted to let you know these are the issues I'm seeing ATM.
>
> I remember this, but I've been at a loss as to why you are getting the
> wrong templates during code insertion.  I was thinking I'd have to
> implement some sort of debugger for template insertion to solve it.  I
> suspect that is a big project.
>
> If anyone else has ideas, I'd like to hear them.

I reported that issue for Mac OS X, but I now also saw it on Linux
(Ubuntu 8.10). I investigated further, and it seems to be a timing
problem with 'autoload, which makes it a bit difficult to debug.

Here's what I observed so far:

The problem ist that foo.hh is not properly set up for parsing, since
semantic-new-buffer-fcn is called with an empty
semantic--parse-table. This problem does not only happen with the
integration test, but always when I start Emacs with the minimal CEDET
setup (i.e. with loaded common/cedet.el and minimum features enabled),
and open a file which uses C++-mode (e.g foo.hh). It seems that in this
case 'semantic-c-by--install-parser' is called *after*
'semantic-new-buffer-fcn' has already run from the
file-load-hook. Therefore, when 'semantic-new-buffer-fcn' is run on
foo.hh, the 'semantic--parse-table' is empty, and hence the buffer is
not properly set up for parsing. This again seems to lead to the wrong
templates being inserted. If I do a (require 'semantic-c) before loading
the first file, everything works fine.

Now, the question is why this happens on a few machines only. I observed
that on that Linux system in question, the semantic-c autoload is pretty
busy with parsing configc++.h; in fact, there are *two* configc++.h
files which are parsed, namely

/usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h
/usr/include/c++/4.3.2/i486-linux-gnu/bits/c++config.h

I included some debug messages in the involved functions and also in the
hooks, and here's the output when I create a new file foo.hh on a fresh
Emacs -q with minimal CEDET setup:

--8<---------------cut here---------------start------------->8---
(New file)
Loading cc-mode...done
DEBUG: Execute c++-mode-hook
Loading /home/david/cedet/semantic/bovine/semantic-c.el (source)...
Loading ring...done
Loading semantic-dep...done
Loading semantic-gcc...done
DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h.
Loading semanticdb-file...done
DEBUG: Execute c++-mode-hook
Loading /home/david/cedet/semantic/bovine/semantic-c.el (source)...
DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h.
DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3.2/i486-linux-gnu/bits/c++config.h.
DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h.
DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3.2/i486-linux-gnu/bits/c++config.h.
DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h.
DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3.2/i486-linux-gnu/bits/c++config.h.
Loading /home/david/cedet/semantic/bovine/semantic-c.el (source)...done
DEBUG: semantic-c-by: installed parser for c++config.h.
DEBUG: Execute find-file-hook
DEBUG: semantic-new-buffer-fcn: called on buffer c++config.h.
DEBUG: semantic-new-buffer-fcn: buffer c++config.h was set up for parsing.
DEBUG: semantic-new-buffer-fcn: called on buffer foo.hh.
DEBUG: semantic-new-buffer-fcn: buffer foo.hh has empty parse table.
DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h.
DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3.2/i486-linux-gnu/bits/c++config.h.
DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h.
DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3.2/i486-linux-gnu/bits/c++config.h.
Loading /home/david/cedet/semantic/bovine/semantic-c.el (source)...done
DEBUG: semantic-c-by: installed parser for foo.hh.
DEBUG: Execute find-file-hook
--8<---------------cut here---------------end--------------->8---

You can see that semantic-new-buffer-fcn is called before the parse
table is installed. Here's the same output when doing this with an
already 'required' semantic-c:

--8<---------------cut here---------------start------------->8---
(New file)
DEBUG: Execute c++-mode-hook
DEBUG: semantic-c-by: installed parser for foo.hh.
DEBUG: Execute find-file-hook
DEBUG: semantic-new-buffer-fcn: called on buffer foo.hh.
DEBUG: semantic-new-buffer-fcn: buffer foo.hh was set up for parsing.
--8<---------------cut here---------------end--------------->8---

Regards,
David