Re[1]: [CEDET-devel] Incremental parser problem

[Eric M. L. <er...@si...>]

This sounds familiar, as though I struggled with it before.
The solution is to always start with the cache after getting the list
of dirty tokens from one of the fetch routines.  (Using eq on the
lists to find a cons match).  I think the splice routine is already
doing this with this code-snippet:

	(let* ((pc (if parent
		       (semantic-nonterminal-children parent)
		     semantic-toplevel-bovine-cache))
	       (nc (cons (car pc) (cdr pc)))  ; new cons cell.
	       )

meaning the list it is splicing into is directly from the cache,
unless the passed in parent token is not originally from the cache.
(An assertion there may answer that question.)

This is some pretty hairy code.  The idea seemed so simple when I
started. ;)

Do you have a reliable reproducible case?

Eric

>>> "David PONCE" <Dav...@wa...> seems to think that:
>Hi Eric,
>
>I think I discovered a nasty problem in the current implementation of
>the incremental parser :-(
>
>In certain cases `semantic-edits-incremental-parser' correctly
>process newly inserted tokens but fails to update the value of
>`semantic-toplevel-bovine-cache'!
>
>After some debugging I found that the problem is in the function
>`semantic-edits-splice-insert' (and maybe
>`semantic-edits-splice-remove' is affected too).  That function
>inserts new tokens by changing the value of the `cache-list' parameter
>by side effect.  The problem is that in some circumstances the value
>of `cache-list' is not a part of `semantic-toplevel-bovine-cache' but
>a different list obtained by consing elements of the cache.  So
>changing the value of `cache-list' will not change the value of
>`semantic-toplevel-bovine-cache'!
>
>For example the problem occurs when `cache-list' is obtained from
>`semantic-find-nonterminal-by-overlay-in-region' which conses in a new
>list the tokens found.  On the contrary there is no problem when
>`cache-list' is obtained from `semantic-nonterminal-children' (that is
>`cache-list' is actually a part of `semantic-toplevel-bovine-cache').
>
>I hope my explanations are clear enough.
>
>I must admit that I don't see how to solve that :-(
>
>Any idea?
  [ ... ]

-- 
          Eric Ludlam:                 za...@gn..., er...@si...
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org