Re: [CEDET-devel] Error Writing Table: #<semanticdb-table test.cxx>

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi Hannes,

I can now replicate the bad behavior with your c hook which is good.  

It turns out it is not a problem with match-data, though I can imagine
it being potentially problematic.

The real problem is that your hook throws an error!  I re-wrote it as
such:

(defun c-mode-style-hook ()
  (let ((path (buffer-file-name)))
    (cond
     ((and path (string-match "/e17-src/" path))
      (c-set-style "e17"))
     )))

and now it is ok.

In it's place, I have wrapped the major-mode initialization on these
special parsing buffers in condition-case to catch these errors, so
perhaps you don't need to add the above fix to your function.

Eric

On Sun, 2009-09-20 at 03:14 +0200, han...@gm... wrote:
> Hello Eric,
> sorry I cant confirm that it is working now . Not sure what it means,
> still the macro is passed five times to
> semantic-lex-spp-anlyzer-do-replace instead of once when not having my
> function set to c-mode-commons-hook.  So the difference is only that
> c-mode-style-hook. Let me know when I should test something.
> 
> Regards,
> Hannes
> 
> 
> c-mode-common-hook's value is
> (c-mode-style-hook
>  (lambda nil
>    (dolist
>        (k
> 	'(":" ">" ";" "<" "{" "}"))
>      (define-key
>        (symbol-value
> 	(make-local-variable 'yas/keymap))
>        k 'self-insert-command))))
> 
> and
> 
> ((lambda nil
>    (dolist
>        (k
> 	'(":" ">" ";" "<" "{" "}"))
>      (define-key
>        (symbol-value
> 	(make-local-variable 'yas/keymap))
>        k 'self-insert-command))))
> 
> 
> On Wed, Sep 16, 2009 at 1:04 PM, Eric M. Ludlam <er...@si...> wrote:
> > Aha!  I checked in a bunch of changes earlier wrapping misc "find file"
> > calls in save-match-data.  The match data is used by the lexer when
> > identifying tokens.  If a "string-match" is done, then a C file found,
> > then a "match-string" is called, the locations in the buffer is stored
> > in the match-data, and the match-string would return something
> > different.  With regard to macro expansion, I found two spots in the
> > macro code that initializes C or C++ mode in a temporary buffer.
> >
> > I checked in a change to wrap those two mode inits in save-match-data
> > which I guess will fix this problem.  If you could try it out, that
> > would be great.
> >
> > Thanks
> > Eric
> >
> >
> > On Wed, 2009-09-16 at 07:36 +0200, han...@gm... wrote:
> >> Hello Eric,
> >> you wont believe me what triggered the problem here. A such harmless
> >> looking hook that I did not consider to disable before:
> >>
> >> (defun c-mode-style-hook ()
> >>   (let ((path (buffer-file-name)))
> >>     (cond
> >>      ((string-match "/e17-src/" path)
> >>       (c-set-style "e17"))
> >>      )))
> >>
> >> (add-hook 'c-mode-common-hook 'c-mode-style-hook)
> >>
> >> Still, I'm absolutely clueless how this could make trouble.
> >>
> >>
> >> Regards,
> >> Hannes
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Sep 16, 2009 at 4:44 AM, Eric M. Ludlam <er...@si...> wrote:
> >> > On Tue, 2009-09-15 at 17:38 +0200, han...@gm... wrote:
> >> >> Hello Eric,
> >> >> with the current version the problem is still here. From my
> >> >> investigations I guess that somewhere in
> >> >> semantic-lex-spp-token-macro-to-macro-stream the macro is not expanded
> >> >> correctly. This is the most simple file that triggers the problem
> >> >> here:
> >> >>
> >> >> #define BLA(name) int name (int);
> >> >> BLA(blub);
> >> >
> >> > I tried this, and it did not have the same result as below.
> >> >
> >> >> C-u M-x bovinate:
> >> >> semantic-lex-spp-anlyzer-do-replace BLA:((spp-arg-list (name) 12 . 18)
> >> >> (INT int 19 . 22) (symbol name 23 . 27) (semantic-list (int) 28 . 33)
> >> >> (punctuation ; 33 . 34))
> >> >> semantic-lex-spp-symbol-push name:(symbol blub 45 . 49) << called in
> >> >> semantic-lex-spp-token-macro-to-macro-stream
> >> >> semantic-lex-spp-symbol-pop name
> >> >> semantic-lex-spp-anlyzer-do-replace BLA:((spp-arg-list (name) 12 . 18)
> >> >> (INT int 19 . 22) (symbol name 23 . 27) (semantic-list (int) 28 . 33)
> >> >> (punctuation ; 33 . 34))
> >> >> semantic-lex-spp-symbol-push name:(symbol blub 45 . 49)
> >> >> semantic-lex-spp-symbol-pop name
> >> >> semantic-lex-spp-anlyzer-do-replace BLA:((spp-arg-list (name) 12 . 18)
> >> >> (INT int 19 . 22) (symbol name 23 . 27) (semantic-list (int) 28 . 33)
> >> >> (punctuation ; 33 . 34))
> >> >> semantic-lex-spp-symbol-push name:(symbol blub 45 . 49)
> >> >> semantic-lex-spp-symbol-pop name
> >> >> semantic-lex-spp-anlyzer-do-replace BLA:((spp-arg-list (name) 12 . 18)
> >> >> (INT int 19 . 22) (symbol name 23 . 27) (semantic-list (int) 28 . 33)
> >> >> (punctuation ; 33 . 34))
> >> >> semantic-lex-spp-symbol-push name:(symbol blub 45 . 49)
> >> >> semantic-lex-spp-symbol-pop name
> >> >> semantic-lex-spp-anlyzer-do-replace BLA:((spp-arg-list (name) 12 . 18)
> >> >> (INT int 19 . 22) (symbol name 23 . 27) (semantic-list (int) 28 . 33)
> >> >> (punctuation ; 33 . 34))
> >> >> semantic-lex-spp-symbol-push name:(symbol blub 45 . 49)
> >> >> semantic-lex-spp-symbol-pop name
> >> >> Retrieving tags took 0.09 seconds.
> >> >
> >> > This indicates all the push/pop operations matched up fine, which
> >> > implies it should not have left name in the symbol table.  In fact, the
> >> > symbol table used is a dynamic one, so it shouldn't be in the global
> >> > table at all.
> >> >
> >> > Since you have handy prints in the code, could you also add what is in
> >> > the stack for the macro being pushed?
> >> > (ie (message "%S" (symbol-value stacksym))
> >> >
> >> > Is it true that if you don't use BLA the macro, then "name" is not in
> >> > the symbol table?
> >> >
> >> >> semantic-lex-spp-describe:
> >> >> Macro         Value
> >> >> BLA           ((spp-arg-list ("name") 12 . 18) (INT "int" 19 . 22) (symbol
> >> >> "name" 23 . 27) (semantic-list "(int)" 28 . 33) (punctuation ";" 33 .
> >> >> 34))
> >> >> name          (symbol "blub" 45 . 49) << this shouldn't be here I guess
> >> >> ...
> >> >>
> >> > Do you also have a pile of GCC macros?
> >> >
> >> >> semanticdb-save-current-db:
> >> >> Saving current tag summaries...
> >> >> Error in macro "(name symbol blub 45 . 49)"
> >> >> Saving current tag summaries...done
> >> >
> >> > Here did you use the patch that allows the save to continue on?
> >> >
> >> >> With my patch the tags are saved like this:
> >> >> ;; Object test/
> >> >> ;; SEMANTICDB Tags save file
> >> >> (semanticdb-project-database-file "test/"
> >> >>   :tables (list
> >> >>    (semanticdb-table "bla.h"
> >> >>     :major-mode 'c-mode
> >> >>     :tags
> >> >>         '( ("BLA" variable (:constant-flag t) nil [9 12]))
> >> >>     :file "bla.h"
> >> >>     :pointmax 53
> >> >>     :fsize 52
> >> >>     :lastmodtime '(19118 57774)
> >> >>     :unmatched-syntax '((punctuation 50 . 51) (punctuation ";" 41 .
> >> >> 50) (semantic-list #("(int)" 0 1 (macros (("name" symbol "blub" 45 .
> >> >> 49)))) 41 . 50) (symbol "blub" 41 . 50) (INT "int" 41 . 50))
> >> >
> >> > I did not get all this unmatched syntax.  I wonder if unmatched syntax
> >> > in a macro is the cause?  I added some in the example, but it had no
> >> > affect similar to the problem you have reported.
> >> >
> >> >>     :lexical-table
> >> >>         '(("BLA" (spp-arg-list ("name") 12 . 18) .
> >> >>               ((INT "int" 19 . 22) (symbol "name" 23 . 27)
> >> >> (semantic-list "(int)" 28 . 33) (punctuation ";" 33 . 34)))
> >> >>           ("name")
> >> >>           )
> >> >
> >> > Mine did not include "name".
> >> >
> >> > I seem to remember I had recommended all sorts of full-reset operations
> >> > in the past which didn't help.  I would guess we need to figure out what
> >> > is different between our setups that would cause this to work for so
> >> > many people, but not for you or Kai.  (I'm also loosing track of who has
> >> > which problem for how long.)
> >> >
> >> > Eric
> >> >
> >
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Cedet-devel mailing list
> Ced...@li...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel