CEDET

Hi, 

On Mac, printf in stdio.h is defined as:

  int	 printf(const char * __restrict, ...) __DARWIN_LDBL_COMPAT(printf);

M-x bovinate gives result as:

 ("__DARWIN_LDBL_COMPAT" function
  (:prototype-flag t :arguments
                   (("" variable
                     (:type
                      ("printf" type
                       (:type "class")
                       nil nil))
                     (reparse-symbol arg-sub-list)
                     #<overlay from 10691 to 10698 in stdio.h>))
                   :type "int")
  (:filename "/usr/include/stdio.h")
  #<overlay from 10670 to 10699 in stdio.h>)

The result is apparently incorrect, since __DARWIN_LDBL_COMPAT is a macro here.
As a result, i'm not able to complete `printf', and lots of other similar
functions.


-William

Re: [CEDET-devel] function parsing bug From: David Engster <deng@ra...> - 2011-06-20 21:32 William Xu writes: > On Mac, printf in stdio.h is defined as: > > int printf(const char * __restrict, ...) __DARWIN_LDBL_COMPAT(printf); > > M-x bovinate gives result as: [...] > The result is apparently incorrect, since __DARWIN_LDBL_COMPAT is a macro here. > As a result, i'm not able to complete `printf', and lots of other similar > functions. These preprocessor macros unfortunately are a common problem. Does (add-to-list 'semantic-lex-c-preprocessor-symbol-map '("__DARWIN_LDBL_COMPAT" . ((spp-arg-list ("foo") 1 . 2)))) help? (You'll have to delete the cached tags in ~/.semanticdb to make Semantic parse the headers again). -David

Re: [CEDET-devel] function parsing bug From: William Xu <william.xwl@gm...> - 2011-06-21 14:23 David Engster <deng <at> randomsample.de> writes: > These preprocessor macros unfortunately are a common problem. Does Hmm... > (add-to-list 'semantic-lex-c-preprocessor-symbol-map > '("__DARWIN_LDBL_COMPAT" . ((spp-arg-list ("foo") 1 . 2)))) > > help? (You'll have to delete the cached tags in ~/.semanticdb to make > Semantic parse the headers again). Yes, that works, thanks. However, there are other many macros around, such as: FILE *fopen(const char * __restrict, const char * __restrict) __DARWIN_EXTSN(fopen); -William

Re: [CEDET-devel] function parsing bug From: David Engster <deng@ra...> - 2011-06-21 20:16 William Xu writes: > David Engster <deng <at> randomsample.de> writes: > >> These preprocessor macros unfortunately are a common problem. Does > > Hmm... > >> (add-to-list 'semantic-lex-c-preprocessor-symbol-map >> '("__DARWIN_LDBL_COMPAT" . ((spp-arg-list ("foo") 1 . 2)))) >> >> help? (You'll have to delete the cached tags in ~/.semanticdb to make >> Semantic parse the headers again). > > Yes, that works, thanks. > > However, there are other many macros around, such as: > > FILE *fopen(const char * __restrict, const char * __restrict) > __DARWIN_EXTSN(fopen); If those macros are defined in a few header files, you can add those to the Semantic parser through (add-to-list 'semantic-lex-c-preprocessor-symbol-file '"/PATH/someheader.h") Semantic should then know all macros in 'someheader.h' when parsing other files. See also http://www.emacswiki.org/emacs/SemanticLibraryParsing -David

Re: [CEDET-devel] function parsing bug From: William Xu <william.xwl@gm...> - 2011-06-22 11:27 David Engster <deng <at> randomsample.de> writes: > See also > > http://www.emacswiki.org/emacs/SemanticLibraryParsing I find: If SOMESYMBOL is defined in some other header file, Semantic will not be able to parse this. The reason for this is that Semantic does not parse every #define’d symbol out there - this would simply make parsing too slow. If the system library has to be parsed only once, i think it is acceptable to parse those macros as well? Finding out and adding those macros is too tedious. -William

Re: [CEDET-devel] function parsing bug From: Eric M. Ludlam <ericludlam@gm...> - 2011-06-22 22:33 On 06/22/2011 07:26 AM, William Xu wrote: > David Engster<deng<at> randomsample.de> writes: > >> See also >> >> http://www.emacswiki.org/emacs/SemanticLibraryParsing > > I find: > > If SOMESYMBOL is defined in some other header file, Semantic will not be > able to parse this. The reason for this is that Semantic does not parse > every #define’d symbol out there - this would simply make parsing too slow. > > If the system library has to be parsed only once, i think it is acceptable to > parse those macros as well? > > Finding out and adding those macros is too tedious. If Mac has a standard set of compiler/library features that always need to be defined, it would probably be easy to update semantic-gcc.el to include the Mac specific features. (Mac uses gcc AFAIK.) On Linux, the preprocessor table is automatically primed from a config header that is easily discovered by asking gcc. On darwin semantic-gcc.el is already beiing used, so tweaking it a little more to fix this would be good. Eric

Re: [CEDET-devel] function parsing bug From: David Engster <deng@ra...> - 2011-06-24 16:56 William Xu writes: > David Engster <deng <at> randomsample.de> writes: > >> See also >> >> http://www.emacswiki.org/emacs/SemanticLibraryParsing > > I find: > > If SOMESYMBOL is defined in some other header file, Semantic will not be > able to parse this. The reason for this is that Semantic does not parse > every #define’d symbol out there - this would simply make parsing too slow. > > If the system library has to be parsed only once, i think it is acceptable to > parse those macros as well? Here's how I remember it: When Semantic parses a file, it first doesn't care for #includes at all (well, except those in semantic-lex-c-preprocessor-symbol-file). It only looks in the #include'd headers if it absolutely has to (if you want a completion, for instance), since if you recursively go down through the #include's, the list of files usually gets large very soon; this is especially true for system includes, and even more for C++ and the STL. While you're right that those files are cached, the tables are often pretty large and have to be loaded and searched for #define's. I think that's more or less the problem, but Eric can probably say more. I think this could be made more efficient by handling #define's separately, but I'm not sure how to best do this and I'm not eager to touch the spp code. Few returned from there. > Finding out and adding those macros is too tedious. As far as I see most macros are defined in asl.h and sys/cdefs.h. What happens when you add those to semantic-lex-c-preprocessor-symbol-file as described? -David

Re: [CEDET-devel] function parsing bug From: William Xu <william.xwl@gm...> - 2011-06-28 13:52 Eric M. Ludlam <ericludlam <at> gmail.com> writes: > If Mac has a standard set of compiler/library features that always need > to be defined, it would probably be easy to update semantic-gcc.el to > include the Mac specific features. (Mac uses gcc AFAIK.) Right, Mac uses gcc. > On Linux, the preprocessor table is automatically primed from a config > header that is easily discovered by asking gcc. On darwin > semantic-gcc.el is already beiing used, so tweaking it a little more to > fix this would be good. Looking at semantic-gcc.el, looks like for c++, it is always looking for this file: /bits/c++config.h. And on mac, there is such file too, so it seems no problem in c++, i can get completions like: std::pri => std::printf. But for c, there is no similar config file? What is the specific part for Linux? such that i can tweak for Mac? -William

Re: [CEDET-devel] function parsing bug From: William Xu <william.xwl@gm...> - 2011-06-28 14:01 David Engster <deng <at> randomsample.de> writes: > Here's how I remember it: When Semantic parses a file, it first doesn't > care for #includes at all (well, except those in > semantic-lex-c-preprocessor-symbol-file). It only looks in the > #include'd headers if it absolutely has to (if you want a completion, > for instance), since if you recursively go down through the #include's, > the list of files usually gets large very soon; this is especially true > for system includes, and even more for C++ and the STL. While you're > right that those files are cached, the tables are often pretty large and > have to be loaded and searched for #define's. I think that's more or > less the problem, but Eric can probably say more. > > I think this could be made more efficient by handling #define's > separately, but I'm not sure how to best do this and I'm not eager to > touch the spp code. Few returned from there. Thanks for the explanation. Now I wonder how other modern IDEs cope with this.. > > Finding out and adding those macros is too tedious. > > As far as I see most macros are defined in asl.h and sys/cdefs.h. What > happens when you add those to semantic-lex-c-preprocessor-symbol-file as > described? No difference regarding the completion. The following function in semantic-gcc.el looks suspicous: (defun semantic-cpp-defs (str) "Convert CPP output STR into a list of cons cells with defines for C++." (let ((lines (split-string str "\n")) (lst nil)) (dolist (L lines) (let ((dat (split-string L))) (when (= (length dat) 3) ; ^^^^^^^^^^^^^^^^^^^^^ (add-to-list 'lst (cons (nth 1 dat) (nth 2 dat)))))) lst)) The marked line seems only capable of handling one specific kind of #define? How about these: #define __deprecated /* nothing */ # define __DARWIN_LDBL_COMPAT(x) /* nothing */ #define __DARWIN_ALIAS_I(sym) __asm("_" __STRING(sym) __DARWIN_SUF_64_BIT_INO_T\ __DARWIN_SUF_UNIX03) >From `/usr/include/sys/cdefs.h'. -William

Re: [CEDET-devel] function parsing bug From: Eric M. Ludlam <ericludlam@gm...> - 2011-07-13 02:22 On 06/28/2011 10:00 AM, William Xu wrote: > David Engster<deng<at> randomsample.de> writes: [...] >> I think this could be made more efficient by handling #define's >> separately, but I'm not sure how to best do this and I'm not eager to >> touch the spp code. Few returned from there. > > Thanks for the explanation. > > Now I wonder how other modern IDEs cope with this.. AFAIK, they were built with a single compiler in mind, and they just use it to do the work. Not sure about eclipse. There is a gccsense that also does this that can be used with Emacs. >>> Finding out and adding those macros is too tedious. >> >> As far as I see most macros are defined in asl.h and sys/cdefs.h. What >> happens when you add those to semantic-lex-c-preprocessor-symbol-file as >> described? > > No difference regarding the completion. > > The following function in semantic-gcc.el looks suspicous: > > (defun semantic-cpp-defs (str) > "Convert CPP output STR into a list of cons cells with defines for C++." > (let ((lines (split-string str "\n")) > (lst nil)) > (dolist (L lines) > (let ((dat (split-string L))) > (when (= (length dat) 3) > ; ^^^^^^^^^^^^^^^^^^^^^ > (add-to-list 'lst (cons (nth 1 dat) (nth 2 dat)))))) > lst)) > > The marked line seems only capable of handling one specific kind of #define? How > about these: > > #define __deprecated /* nothing */ > # define __DARWIN_LDBL_COMPAT(x) /* nothing */ > #define __DARWIN_ALIAS_I(sym) __asm("_" __STRING(sym) __DARWIN_SUF_64_BIT_INO_T\ > __DARWIN_SUF_UNIX03) > >> From `/usr/include/sys/cdefs.h'. The problem here is that to parse the define you specify below, you need a file in C or C++ mode from which to do the parsing. The line you specified was for parsing the output of gcc when it dumps out a bunch of symbols specifying gcc defaults. Thus, I don't think the code you found will parse the file you found. Instead, semantic-gcc should just add sys/cdefs into the list of files to get macros from, and then it will be ok. There is a line in semantic-gcc such as: (let ((cppconfig (concat D "/bits/c++config.h"))) I'll guess that we want to add sys/cdefs.h into that mechanism also for all platforms, as it looks useful for linux also. Perhaps someone could try to put a patch together for that? Thanks Eric

Re: [CEDET-devel] function parsing bug From: William Xu <william.xwl@gm...> - 2011-07-13 14:50 > >> From `/usr/include/sys/cdefs.h'. > > The problem here is that to parse the define you specify below, you need > a file in C or C++ mode from which to do the parsing. The line you > specified was for parsing the output of gcc when it dumps out a bunch of > symbols specifying gcc defaults. > > Thus, I don't think the code you found will parse the file you found. > Instead, semantic-gcc should just add sys/cdefs into the list of files > to get macros from, and then it will be ok. Do you mean something like this? (add-to-list 'semantic-lex-c-preprocessor-symbol-file "/usr/include/sys/cdefs.h") I add above to .emacs, exit emacs, delete ~/.semanticdb, then start emacs again. But it still doesn't work for me.. -William

Re: [CEDET-devel] function parsing bug From: Eric M. Ludlam <ericludlam@gm...> - 2011-07-14 11:41 On 07/13/2011 10:50 AM, William Xu wrote: >>>> From `/usr/include/sys/cdefs.h'. >> >> The problem here is that to parse the define you specify below, you need >> a file in C or C++ mode from which to do the parsing. The line you >> specified was for parsing the output of gcc when it dumps out a bunch of >> symbols specifying gcc defaults. >> >> Thus, I don't think the code you found will parse the file you found. >> Instead, semantic-gcc should just add sys/cdefs into the list of files >> to get macros from, and then it will be ok. > > Do you mean something like this? > > (add-to-list 'semantic-lex-c-preprocessor-symbol-file > "/usr/include/sys/cdefs.h") > > I add above to .emacs, exit emacs, delete ~/.semanticdb, then start emacs > again. But it still doesn't work for me.. Yes, that is it. Deleting your .semanticdb directory is the right thing to doo too. I don't know why that wouldn't work unless the macro you want has some syntax that semantic doesn't support. To figure that out, load the cdefs.h macro you want into a buffer and see if it parses. if it doesn't, perhaps it is wrapping in an #if whose test is false because some other variable is false. Eric

Re: [CEDET-devel] function parsing bug From: William Xu <william.xwl@gm...> - 2011-07-23 08:10 Eric M. Ludlam <ericludlam <at> gmail.com> writes: > > Do you mean something like this? > > > > (add-to-list 'semantic-lex-c-preprocessor-symbol-file > > "/usr/include/sys/cdefs.h") > > > > I add above to .emacs, exit emacs, delete ~/.semanticdb, then start emacs > > again. But it still doesn't work for me.. > > Yes, that is it. Deleting your .semanticdb directory is the right thing > to doo too. I don't know why that wouldn't work unless the macro you > want has some syntax that semantic doesn't support. > > To figure that out, load the cdefs.h macro you want into a buffer and > see if it parses. if it doesn't, perhaps it is wrapping in an #if whose > test is false because some other variable is false. Three findings. 1. `cpp' command gives error on Mac: ~ $ cpp "-E" "-dM" "-x" "c++" /dev/null i686-apple-darwin10-gcc-4.2.1: c: No such file or directory i686-apple-darwin10-gcc-4.2.1: c++: No such file or directory i686-apple-darwin10-gcc-4.2.1: warning: '-x -x' after last input file has no effect i686-apple-darwin10-gcc-4.2.1: no input files I have to replace it with gcc. See patch in the end. Any difference between `cpp' and `gcc' here? 2. Simply adding cdefs.h to the semantic-lex-c-preprocessor-symbol-file doesn't work as expected. After several tries, the following finally makes the completion works. (let ((f "/usr/include/sys/cdefs.h")) (save-window-excursion (with-current-buffer (find-file-noselect f) (bovinate)) (add-to-list 'semantic-lex-c-preprocessor-symbol-file f) (semantic-gcc-setup))) Why? 3. I found CEDET has semantic-clang.el, and it simply works much more nicely than semantic-gcc.el.. -William --- semantic/bovine/semantic-gcc.el 2010-10-02 02:20:49 +0000 +++ semantic/bovine/semantic-gcc.el 2011-07-23 03:30:26 +0000 @@ -144,7 +144,7 @@ (interactive) (let* ((fields (or semantic-gcc-setup-data (semantic-gcc-fields (semantic-gcc-query "gcc" "-v")))) - (defines (semantic-cpp-defs (semantic-gcc-query "cpp" "-E" "-dM" "-x" "c++" null-device))) + (defines (semantic-cpp-defs (semantic-gcc-query "gcc" "-E" "-dM" "-x" "c++" null-device))) (ver (cdr (assoc 'version fields))) (host (or (cdr (assoc 'target fields)) (cdr (assoc '--target fields))

Re: [CEDET-devel] function parsing bug From: Eric M. Ludlam <ericludlam@gm...> - 2011-07-30 17:30 On 07/23/2011 04:09 AM, William Xu wrote: > Eric M. Ludlam<ericludlam<at> gmail.com> writes: > >>> Do you mean something like this? >>> >>> (add-to-list 'semantic-lex-c-preprocessor-symbol-file >>> "/usr/include/sys/cdefs.h") >>> >>> I add above to .emacs, exit emacs, delete ~/.semanticdb, then start emacs >>> again. But it still doesn't work for me.. >> >> Yes, that is it. Deleting your .semanticdb directory is the right thing >> to doo too. I don't know why that wouldn't work unless the macro you >> want has some syntax that semantic doesn't support. >> >> To figure that out, load the cdefs.h macro you want into a buffer and >> see if it parses. if it doesn't, perhaps it is wrapping in an #if whose >> test is false because some other variable is false. > > Three findings. > > 1. `cpp' command gives error on Mac: > > ~ $ cpp "-E" "-dM" "-x" "c++" /dev/null > i686-apple-darwin10-gcc-4.2.1: c: No such file or directory > i686-apple-darwin10-gcc-4.2.1: c++: No such file or directory > i686-apple-darwin10-gcc-4.2.1: warning: '-x -x' after last input file has no > effect > i686-apple-darwin10-gcc-4.2.1: no input files > > I have to replace it with gcc. See patch in the end. Any difference between > `cpp' and `gcc' here? That should be easy to get going. We could test the exit code of the cpp call, and use gcc if it fails. Would someone like to give this a try? > 2. Simply adding cdefs.h to the semantic-lex-c-preprocessor-symbol-file doesn't > work as expected. After several tries, the following finally makes the > completion works. > > (let ((f "/usr/include/sys/cdefs.h")) > (save-window-excursion > (with-current-buffer (find-file-noselect f) > (bovinate)) > (add-to-list 'semantic-lex-c-preprocessor-symbol-file f) > (semantic-gcc-setup))) > > Why? Hmmm. If you set semantic-lex-c-preprocessor-symbol-file in your .emacs file before loading in CEDET, it should work fine. If you want to modify it after the fact, you either need to use customize-symbol, or use (semantic-c-reset-preprocessor-symbol-map) immediately afterward to force the symbols to refresh. I think semantic-gcc-setup is just resetting the map in your above example since it also tries to modify the preprocessor-symbol-file list. Patching semantic-gcc to do that add automatically will be better. > 3. I found CEDET has semantic-clang.el, and it simply works much more nicely > than semantic-gcc.el.. Yes, it has it's own advantages when looking at just the code-completion feature and is very worth while. Eric

Re: [CEDET-devel] function parsing bug From: William Xu <william.xwl@gm...> - 2011-08-03 01:57 "Eric M. Ludlam" <ericludlam@...> writes: That should be easy to get going. We could test the exit code of the cpp call, and use gcc if it fails. Would someone like to give this a try? How about this patch? (in the end) Hmmm. If you set semantic-lex-c-preprocessor-symbol-file in your .emacs file before loading in CEDET, it should work fine. If you want to modify it after the fact, you either need to use customize-symbol, or use (semantic-c-reset-preprocessor-symbol-map) immediately afterward to force the symbols to refresh. I've thought that too, by setting semantic-lex-c-preprocessor-symbol-file before loading CEDET. But it still doesn't work for me.. -- William http://xwl.appspot.com === modified file 'semantic/bovine/semantic-gcc.el' --- semantic/bovine/semantic-gcc.el 2010-10-02 02:20:49 +0000 +++ semantic/bovine/semantic-gcc.el 2011-07-31 15:07:52 +0000 @@ -29,30 +29,32 @@ ;;; Code: (defun semantic-gcc-query (gcc-cmd &rest gcc-options) - "Return program output to both standard output and standard error. + "Return program output or error code in case error happens. GCC-CMD is the program to execute and GCC-OPTIONS are the options to give to the program." ;; $ gcc -v ;; - (let ((buff (get-buffer-create " *gcc-query*")) - (old-lc-messages (getenv "LC_ALL"))) + (let* ((buff (get-buffer-create " *gcc-query*")) + (old-lc-messages (getenv "LC_ALL")) + (options `(,nil ,(cons buff t) ,nil ,@gcc-options)) + (err 0)) (with-current-buffer buff (erase-buffer) (setenv "LC_ALL" "C") (condition-case nil - (apply 'call-process gcc-cmd nil (cons buff t) nil gcc-options) + (setq err (apply 'call-process gcc-cmd options)) (error ;; Some bogus directory for the first time perhaps? (let ((default-directory (expand-file-name "~/"))) (condition-case nil - (apply 'call-process gcc-cmd nil (cons buff t) nil gcc-options) + (setq err (apply 'call-process gcc-cmd options)) (error ;; gcc doesn't exist??? nil))))) (setenv "LC_ALL" old-lc-messages) (prog1 - (buffer-string) - (kill-buffer buff) - ) - ))) + (if (zerop err) + (buffer-string) + err) + (kill-buffer buff))))) ;;(semantic-gcc-get-include-paths "c") ;;(semantic-gcc-get-include-paths "c++") @@ -144,7 +146,14 @@ (interactive) (let* ((fields (or semantic-gcc-setup-data (semantic-gcc-fields (semantic-gcc-query "gcc" "-v")))) - (defines (semantic-cpp-defs (semantic-gcc-query "cpp" "-E" "-dM" "-x" "c++" null-device))) + (cpp-options `("-E" "-dM" "-x" "c++" ,null-device)) + (query (let ((q (apply 'semantic-gcc-query "cpp" cpp-options))) + (if (stringp q) + q + ;; `cpp' command in `semantic-gcc-setup' doesn't work on + ;; Mac, try `gcc'. + (apply 'semantic-gcc-query "gcc" cpp-options)))) + (defines (semantic-cpp-defs query)) (ver (cdr (assoc 'version fields))) (host (or (cdr (assoc 'target fields)) (cdr (assoc '--target fields))

Re: [CEDET-devel] function parsing bug From: David Engster <deng@ra...> - 2011-10-11 18:37 William Xu writes: > On Mac, printf in stdio.h is defined as: > > int printf(const char * __restrict, ...) __DARWIN_LDBL_COMPAT(printf); > > M-x bovinate gives result as: > > ("__DARWIN_LDBL_COMPAT" function [...] > The result is apparently incorrect, since __DARWIN_LDBL_COMPAT is a macro here. > As a result, i'm not able to complete `printf', and lots of other similar > functions. It's been a while, but I pushed some changes which should now parse libc on Darwin out of the box. This also involved fixing a pretty nasty bug which prevented the files in semantic-lex-c-preprocessor-symbol-file from being parsed when they weren't already cached. Cheers, David

Re: [CEDET-devel] function parsing bug From: Eric M. Ludlam <ericludlam@gm...> - 2012-01-21 16:50 On 08/02/2011 09:56 PM, William Xu wrote: > "Eric M. Ludlam"<ericludlam@...> writes: > > That should be easy to get going. We could test the exit code of the > cpp call, and use gcc if it fails. > > Would someone like to give this a try? > > How about this patch? (in the end) > Sorry about the long delay. I have committed you patch to semantic-gcc so it will try the fallback when cpp doesn't work. For those using CEDET on a MAC, please give this a try to see if things improve. You may need to delete your ~/.semanticdb directory to get the updated preprocessor symbols to work. Eric

1 message has been excluded from this view by a project administrator.