Subject: bug#23271: CC Mode 5.33 (C/l); Cache failure

From: Alan Mackenzie <[email-masked]>
Date: Thu, 5 May 2016 19:15:38 +0000

Hello, Michael.

On Tue, Apr 26, 2016 at 04:18:50PM -0400, Michael Welsh Duggan wrote:
> Alan Mackenzie <[email-masked]> writes:

> > Sorry about the delayed response.

> > I think I've tracked down what is causing this cache failure, but I'm
> > not yet totally convinced by my patch for it.

Now, I don't think I was right.

> > It seems to be an error in adjusting the cache when the buffer gets
> > narrowed.  In particular, when the new point-min is inside a brace pair
> > which was previously recorded in the cache.

> > Give me a little time, and I'll get back to you with a patch.

> Sure.  I (obviously) normally run with cache debugging turned on, and I
> get cache errors fairly frequently.  Unfortunately, I can really only
> send you the ones I can reproduce.  Each time I hope that the bug fixed
> includes all of the errors I see.  :)

I think the issue here is `open-paren-in-column-0-is-defun-start'.  In

>> c-parse-state inconsistency at 33929: using cache: (33928 33838 (32429 . 33731) 795 365), from scratch: (33928 33838 (32429 . 33731))

, the brace pair (32429 . 33731)'s opener at 32429 is in column zero.
So, if `open-paren-...-start' is non-nil, the low level syntax routines
aren't going to be scanning back any further than that.  I think, in
this case, the braces at 365 and 795 got into the cache early on, and
stayed there.

Would you check your setting of that variable, please, and if it's
non-nil, try setting it to nil to see if the inconsistency goes away.
If it's already nil, please let me know, in which case I've got some
serious head scratching to do.

> -- 
> Michael Welsh Duggan
> ([email-masked])

-- 
Alan Mackenzie (Nuremberg, Germany).