Thread: [CEDET-devel] Parsing standard C++ includes
Brought to you by:
zappo
From: Alastair R. <ar...@in...> - 2009-02-17 07:56:06
|
So I'm finding it difficult to get semantic to parse system includes unless they have a ".h" or ".hpp" file extension. Does this rely on emacs' auto major mode detection to work correctly? Given a sample file main.cpp with two includes, assert.h and iostream, both appear as unparsed when the file is first loaded. I can right click on the assert.h include and select parse this include. This works fine. Do the same for iostream but no luck. The result is that iostream remains unparsed: Include Summary for File: /Users/alastair/hack/cedetsandbox/main.cpp This file contains 3 tags, 2 of which are includes. Unknown Includes: 0 Unparsed Includes: 1 Parsed Includes: 1 Include Path Summary: This file's project include search is handled by the EDE object: Buffer Target: #<ede-proj-target-makefile-program cedetsandbox> Buffer Project: #<ede-proj-project cedetsandbox> Backup Locator: #<ede-locate-base Loc> This file's system include path is: /usr/include/ /usr/include/c++/4.0.0/ /usr/include/c++/4.0.0/i686-apple-darwin9/ All unknown includes: iostream Summary of all includes needed by main.cpp main.cpp : 3 tags, 2 are includes. assert.h : 5 tags, 1 are includes. cdefs.h : 56 tags, 0 are includes. However if I right click on iostream and select Visit This Include, it parses just fine. Now if I re-load main.cpp, iostream is parsed, but the files that are included by iostream - namely istream and ostream - aren't. Looking further it seems that other non-standard file extensions are not parsed either (eg stdlibc++ includes a .tcc file). Differing file extensions seems to be the deciding factor here and I'd like to be able to track it down any further. The files in question have the relevant mode detection strings so that emacs correctly identifies them as c++ files, and invokes the corresponding mode. However semantic does not seem able to take advantage of this. Suggestions appreciated. |
From: Eric M. L. <er...@si...> - 2009-02-21 12:26:14
|
Hi, Do you know when the major-mode for your header files like iostream is set up? I did this: M-x debug-on-entry RET c++-mode RET C-x C-f /usr/include/c++/iostream RET and it tells me it is set in set-auto-mode. M-x cancel-debug-on-entry RET The database code that loads and parses headers turns off many features, but leaves on set-auto-mode so the parsing can work. If the major mode is set via some other hook, then this would be the cause. As I don't have this problem, you can look in semantic-fw.el for semantic-find-file-noselect to try and identify the disabled feature that you need to re-enable. Let me know how it goes. Eric >>> Alastair Rankine <ar...@in...> seems to think that: >So I'm finding it difficult to get semantic to parse system includes >unless they have a ".h" or ".hpp" file extension. Does this rely on >emacs' auto major mode detection to work correctly? > >Given a sample file main.cpp with two includes, assert.h and iostream, >both appear as unparsed when the file is first loaded. I can right >click on the assert.h include and select parse this include. This >works fine. Do the same for iostream but no luck. The result is that >iostream remains unparsed: > > >Include Summary for File: /Users/alastair/hack/cedetsandbox/main.cpp > >This file contains 3 tags, 2 of which are includes. > Unknown Includes: 0 > Unparsed Includes: 1 > Parsed Includes: 1 > >Include Path Summary: > > This file's project include search is handled by the EDE object: > Buffer Target: #<ede-proj-target-makefile-program cedetsandbox> > Buffer Project: #<ede-proj-project cedetsandbox> > Backup Locator: #<ede-locate-base Loc> > > This file's system include path is: > /usr/include/ > /usr/include/c++/4.0.0/ > /usr/include/c++/4.0.0/i686-apple-darwin9/ > >All unknown includes: > iostream > >Summary of all includes needed by main.cpp > main.cpp : 3 tags, 2 are includes. > assert.h : 5 tags, 1 are includes. > cdefs.h : 56 tags, 0 are includes. > > >However if I right click on iostream and select Visit This Include, it >parses just fine. Now if I re-load main.cpp, iostream is parsed, but >the files that are included by iostream - namely istream and ostream - >aren't. > >Looking further it seems that other non-standard file extensions are >not parsed either (eg stdlibc++ includes a .tcc file). > >Differing file extensions seems to be the deciding factor here and I'd >like to be able to track it down any further. > >The files in question have the relevant mode detection strings so that >emacs correctly identifies them as c++ files, and invokes the >corresponding mode. However semantic does not seem able to take >advantage of this. [ ... ] |
From: Alastair R. <ar...@in...> - 2009-02-21 23:11:17
|
On 21/02/2009, at 11:26 PM, Eric M. Ludlam wrote: > The database code that loads and parses headers turns off many > features, but leaves on set-auto-mode so the parsing can work. If the > major mode is set via some other hook, then this would be the cause. > > As I don't have this problem, you can look in semantic-fw.el for > semantic-find-file-noselect to try and identify the disabled feature > that you need to re-enable. > > Let me know how it goes. Yep, well it's setting the mode using set-auto-mode, but this seems to be relying on local variables, which is disabled in semantic-find-file- noselect. Leaving local variables enabled seems to fix the problem: === modified file 'semantic/semantic-fw.el' --- semantic/semantic-fw.el 2009-02-04 12:45:50 +0000 +++ semantic/semantic-fw.el 2009-02-21 22:57:29 +0000 @@ -430,7 +430,7 @@ ;; Don't prompt to insert a template if we visit an empty file (auto-insert nil) ;; We don't want emacs to query about unsafe local variables - (enable-local-variables nil) + ;(enable-local-variables nil) ;; ... or eval variables (enable-local-eval nil) ) This isn't an ideal fix; as the comment indicates there is still the possibility of a warning about unsafe local variables. However I don't see an alternative - according to the doco for enable-local-variables, it also controls setting the mode appropriately. |
From: DaveS <da...@te...> - 2009-02-22 04:25:10
|
On Sun, 22 Feb 2009 10:11:02 +1100 Alastair Rankine <ar...@in...> wrote: > On 21/02/2009, at 11:26 PM, Eric M. Ludlam wrote: > [...] > > Yep, well it's setting the mode using set-auto-mode, but this seems to > be relying on local variables, which is disabled in semantic-find-file- > noselect. Leaving local variables enabled seems to fix the problem: > > === modified file 'semantic/semantic-fw.el' > --- semantic/semantic-fw.el 2009-02-04 12:45:50 +0000 > +++ semantic/semantic-fw.el 2009-02-21 22:57:29 +0000 > @@ -430,7 +430,7 @@ > ;; Don't prompt to insert a template if we visit an empty file > (auto-insert nil) > ;; We don't want emacs to query about unsafe local variables > - (enable-local-variables nil) > + ;(enable-local-variables nil) > ;; ... or eval variables > (enable-local-eval nil) > ) > > This isn't an ideal fix; as the comment indicates there is still the > possibility of a warning about unsafe local variables. However I don't > see an alternative - according to the doco for enable-local-variables, > it also controls setting the mode appropriately. I'm the one that requested the change for enable-local-variables (the warnings about unsafe local variables can really get annoying). The docs are a bit unclear but I wonder if setting enable-local-variables to :safe will be enough for the set-auto-mode magic to still work. If so then I think everyone wins. -- DS |
From: Eric M. L. <er...@si...> - 2009-02-22 13:29:40
|
>>> DaveS <da...@te...> seems to think that: >On Sun, 22 Feb 2009 10:11:02 +1100 Alastair Rankine <ar...@in...> wrote: >> On 21/02/2009, at 11:26 PM, Eric M. Ludlam wrote: [ ... ] >> Yep, well it's setting the mode using set-auto-mode, but this seems to >> be relying on local variables, which is disabled in semantic-find-file- >> noselect. Leaving local variables enabled seems to fix the problem: >> >> === modified file 'semantic/semantic-fw.el' >> --- semantic/semantic-fw.el 2009-02-04 12:45:50 +0000 >> +++ semantic/semantic-fw.el 2009-02-21 22:57:29 +0000 >> @@ -430,7 +430,7 @@ >> ;; Don't prompt to insert a template if we visit an empty file >> (auto-insert nil) >> ;; We don't want emacs to query about unsafe local variables >> - (enable-local-variables nil) >> + ;(enable-local-variables nil) >> ;; ... or eval variables >> (enable-local-eval nil) >> ) >> >> This isn't an ideal fix; as the comment indicates there is still the >> possibility of a warning about unsafe local variables. However I don't >> see an alternative - according to the doco for enable-local-variables, >> it also controls setting the mode appropriately. > >I'm the one that requested the change for enable-local-variables (the >warnings about unsafe local variables can really get annoying). The docs >are a bit unclear but I wonder if setting enable-local-variables to :safe >will be enough for the set-auto-mode magic to still work. If so then I >think everyone wins. I checked the doc, and Emacs 21, and XEmacs 21.4 don't have the nifty :safe feature. For them :safe means to ask the user. At the same time, only Emacs 23 seems to indicate that this variable controls looking up modes in a -*- line. Perhaps that is an oversight in older version of the doc? It would be handy if an XEmacs user could look up any options on newer versions of XEmacs. Thanks Eric *** semantic-fw.el.~1.71.~ 2009-02-04 07:45:50.000000000 -0500 --- semantic-fw.el 2009-02-22 08:27:25.000000000 -0500 *************** *** 430,436 **** ;; Don't prompt to insert a template if we visit an empty file (auto-insert nil) ;; We don't want emacs to query about unsafe local variables ! (enable-local-variables nil) ;; ... or eval variables (enable-local-eval nil) ) --- 430,443 ---- ;; Don't prompt to insert a template if we visit an empty file (auto-insert nil) ;; We don't want emacs to query about unsafe local variables ! (enable-local-variables ! (if (featurep 'xemacs) ! ;; XEmacs only has nil as an option? ! nil ! ;; Emacs 23 has the spiffy :safe option, nil otherwise. ! (if (inversion-check-version emacs-version nil '(full 23 0)) ! nil ! :safe))) ;; ... or eval variables (enable-local-eval nil) ) |
From: DaveS <da...@te...> - 2009-02-22 20:16:30
|
On Sun, Feb 22 2009, Marcus Harnisch wrote: > "Eric M. Ludlam" <er...@si...> writes: > >> I checked the doc, and Emacs 21, and XEmacs 21.4 don't have the nifty >>:safe feature. For them :safe means to ask the user. At the same >> time, only Emacs 23 seems to indicate that this variable controls >> looking up modes in a -*- line. Perhaps that is an oversight in older >> version of the doc? >> >> It would be handy if an XEmacs user could look up any options on newer >> versions of XEmacs. > > XEmacs 21.5.28 doesn't have it and neither does Emacs 22.2.1 (the > latter from Ubuntu 8.10). > > > Regards > Marcus Ugh. I've got Emacs 22.3.1. I'm assuming that's where :safe was first introduced. I did a quick check and it looks like -*- mode lines are parsed when enable-local-variables is set to :safe. Obviously the number one priority is ensuring that parsing works correctly on all platforms. Could we do a bit of inspection and do a best choice based on the user's platform. Barring that, how about exposing this so a knowledgeable user can specify a value if they choose. -- DS |
From: Alastair R. <ar...@in...> - 2009-02-22 20:35:57
|
On 23/02/2009, at 7:15 AM, DaveS wrote: >> > Obviously the number one priority is ensuring that parsing works > correctly > on all platforms. Could we do a bit of inspection and do a best > choice > based on the user's platform. Barring that, how about exposing this > so a > knowledgeable user can specify a value if they choose. Another idea occurred to me. The mode of the new file is almost certainly going to match that of the parsed parent file. In other words, if we are parsing a c++ file, then all of the #included files can be parsed as c++ as well. Hence as a fallback, if after loading the file with find-file-noselect we find that there is no mode set, we can attempt to parse it using whatever the parent (not sure if that's the right terminology here) file's mode is. |
From: Eric M. L. <er...@si...> - 2009-02-23 03:07:57
|
>>> DaveS <da...@te...> seems to think that: >On Sun, Feb 22 2009, Marcus Harnisch wrote: >> "Eric M. Ludlam" <er...@si...> writes: >> >>> I checked the doc, and Emacs 21, and XEmacs 21.4 don't have the nifty >>>:safe feature. For them :safe means to ask the user. At the same >>> time, only Emacs 23 seems to indicate that this variable controls >>> looking up modes in a -*- line. Perhaps that is an oversight in older >>> version of the doc? >>> >>> It would be handy if an XEmacs user could look up any options on newer >>> versions of XEmacs. >> >> XEmacs 21.5.28 doesn't have it and neither does Emacs 22.2.1 (the >> latter from Ubuntu 8.10). >> >> >> Regards >> Marcus > >Ugh. I've got Emacs 22.3.1. I'm assuming that's where :safe was first >introduced. I did a quick check and it looks like -*- mode lines are >parsed when enable-local-variables is set to :safe. > >Obviously the number one priority is ensuring that parsing works correctly >on all platforms. Could we do a bit of inspection and do a best choice >based on the user's platform. Barring that, how about exposing this so a >knowledgeable user can specify a value if they choose. Thanks for the info. I'll use 22.3 as the starting version using :safe. For versions of Emacs without :safe, I'm not sure what value they would set this to, regardless of how savvy they are. A mechanical hook would be needed instead to disable/enable additional things. That could be tricky since the bindings need to be temporary. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Eric M. L. <er...@si...> - 2009-02-23 03:22:26
|
>>> Alastair Rankine <ar...@in...> seems to think that: > >On 23/02/2009, at 7:15 AM, DaveS wrote: >>> >> Obviously the number one priority is ensuring that parsing works >> correctly >> on all platforms. Could we do a bit of inspection and do a best >> choice >> based on the user's platform. Barring that, how about exposing this >> so a >> knowledgeable user can specify a value if they choose. > >Another idea occurred to me. The mode of the new file is almost >certainly going to match that of the parsed parent file. In other >words, if we are parsing a c++ file, then all of the #included files >can be parsed as c++ as well. Hence as a fallback, if after loading >the file with find-file-noselect we find that there is no mode set, we >can attempt to parse it using whatever the parent (not sure if that's >the right terminology here) file's mode is. [ ... ] I've contemplated this. I use this technique for the ctags parsing, since the actual file isn't loaded. I also use it when I create database objects tied to a file without ever loading the file in. I've been hesitant to make these assumptions because there might not be a starting file to derive a major-mode from. For example, if someone wanted to pre-parse /usr/include/c++ then there is no starting buffer to derive a mode from. On the flip side, such an assumption would be handy for cases where a .cpp file includes a .h file full of "#ifdef cplusplus" blocks that you want parsed in C++ mode, not C mode. This is, as far as I can tell, a problem unique to C/C++. It also exposes issues I have where I try to parse .h files once, but the preprocessor symbols active can change on a per-file basis. As such, the best thing I can think to do is to allow Emacs to read a file into a buffer, and choose the mode for me. I like it because I don't have to do anything special. Or so I'd like to think anyway. :) We just need to tune this special semantic-find-file-noselect to have the best set of disabling settings. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Marcus H. <mar...@gm...> - 2009-02-22 15:36:29
|
"Eric M. Ludlam" <er...@si...> writes: > I checked the doc, and Emacs 21, and XEmacs 21.4 don't have the nifty > :safe feature. For them :safe means to ask the user. At the same > time, only Emacs 23 seems to indicate that this variable controls > looking up modes in a -*- line. Perhaps that is an oversight in older > version of the doc? > > It would be handy if an XEmacs user could look up any options on newer > versions of XEmacs. XEmacs 21.5.28 doesn't have it and neither does Emacs 22.2.1 (the latter from Ubuntu 8.10). Regards Marcus -- note that "property" can also be used as syntaxtic sugar to reference a property, breaking the clean design of verilog; [...] (seen on http://www.veripool.com/verilog-mode_news.html) |
From: Marcus H. <mar...@gm...> - 2009-02-23 13:10:57
|
Marcus Harnisch <mar...@gm...> writes: > XEmacs 21.5.28 doesn't have it True. > and neither does Emacs 22.2.1 (the latter from Ubuntu 8.10). Rubbish! What was I thinking? Here is the docstring. ,----[ enable-local-variables ] | enable-local-variables is a variable defined in `files.el'. | Its value is t | | | Documentation: | Control use of local variables in files you visit. | The value can be t, nil, :safe, :all or something else. | | A value of t means file local variables specifications are obeyed | if all the specified variable values are safe; if any values are | not safe, Emacs queries you, once, whether to set them all. | (When you say yes to certain values, they are remembered as safe.) | | :safe means set the safe variables, and ignore the rest. | :all means set all variables, whether safe or not. | (Don't set it permanently to :all.) | A value of nil means always ignore the file local variables. | | Any other value means always query you once whether to set them all. | (When you say yes to certain values, they are remembered as safe, but | this has no effect when `enable-local-variables' is "something else".) | | This variable also controls use of major modes specified in | a -*- line. | | The command M-x normal-mode, when used interactively, | always obeys file local variable specifications and the -*- line, | and ignores this variable. | | You can customize this variable. `---- -- Marcus |