bug#11749: Acknowledgement (24.1; C-mode indentation gives wrong-type-argument error.)

[Alan Mackenzie]

Hi, Michael,

On Tue, Oct 09, 2012 at 10:05:07AM -0400, Michael Welsh Duggan wrote:
> Alan Mackenzie <acm@muc.de> writes:

[ .... ]

> >> >>> M-x c-toggle-parse-state-debug

> >> >>> It works by calculating c-parse-state twice for each call - The first
> >> >>> time normally, then again with the internal state bound to "newly
> >> >>> initialised".  If the the two results differ, they are printed to
> >> >>> *Messages*, together with the saved previous state.  If this does
> >> >>> trigger, please note any recent buffer changes.  It may make editing
> >> >>> intolerably slow.

> >> >> I will turn this on.

> >> I turned this on, and inserted a (ding) where cc-mode outputs an
> >> inconsistency message.  I can barely stand to edit code now, due to
> >> what seem to be almost every key press causing a beep.  Have you made
> >> any progress here, or do you need more data?

> > I have found the bug which is causing (most of) these dings, though I
> > don't think it is the one which caused Kim's original bug.  Could you try
> > out the patch below, please.  (I have also enhanced/corrected the
> > debugging routines a bit, too.)

> Still doesn't seem to help much here.  I have attached a file which
> reliably causes a cache failure.  I have attached the smallest file of
> the set of files I am working on that causes this particular problem.
> Load the attached file and toggle on parse state debugging.  Then scroll
> to the bottom of the file.  (Use C-v multiple times, or just M->.)  One
> reason I have attached this file is that it only triggers the warning
> message once.  Most of my larger files cause this to happen quite a lot.

What is happening in this file is another bug, arising from historical
assumptions which are no longer valid.

The "from scratch" calculation notes that the starting scanning position
would be a long way (>5000) back, hence it tries going back to the second
"beginning-of-defun" to get a top-level starting point.  This
"beginning-of-defun" is a pure "brace in column zero" test.

This doesn't work in C++ when constructs inside a namespace have braces
at column zero, something I believe has become very common in recent
years.  Namespaces didn't exist in C++ when c-parse-state was originally
written.

Obviously this optimisation is no longer valid.  I wouldn't be surprised
if it has caused quite a bit of buggy behaviour.  I'll need to think it
over for a few days to decide what to do.

Again, thanks for taking so much trouble in submitting these bug
reports.


> -- 
> Michael Welsh Duggan
> (mwd@cert.org)

-- 
Alan Mackenzie (Nuremberg, Germany).