bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer

[Paul Nelson <ultrono@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4446 bytes --]

Hi all,

Thanks for your responses.  Alan's suggestion "M-: (def-edebug-spec
c-save-buffer-state let*)" allowed me to debug the original issue in more
detail.

In summary, the issue goes away entirely if I simply C-M-x the function
c-determine-limit-no-macro before doing anything.  What baffles me is why
that function should behave differently after C-M-x'ing (perhaps something
to do with emacs compilation, which I'm not so familiar with).

Before diving into the details, let me note that the issue does not appear
to be an isolated peculiarity related to inserting large chunks of code --
the same bug has shown up repeatedly the past few days in more "organic"
situations involving normal C++ code.  The example noted in my original
report remains the simplest reproducible one that I've found.

The part of c-guess-basic-syntax that generates the error ("Wrong type
argument: number-or-marker-p, nil") is the following:

  ;; CASE 5B: After a function header but before the body (or
;; the ending semicolon if there's no body).
((save-excursion
   (when (setq placeholder (c-just-after-func-arglist-p
    (max lim (c-determine-limit 500))))
     (setq tmp-pos (point))))
 (cond

The issue is that (c-determine-limit 500) returns nil, which is an invalid
argument to ~max~.

When I instrument and step through the offending invocation of
c-determine-limit, the execution passes through the second branch of the
final ~cond~ clause, which reads as follows:

((>= count how-far-back)
 (c-determine-limit-no-macro
 (+ (car elt) (- count how-far-back))
 org-start))

Stepping through the above code block in edebug using SPC, the function
c-determine-limit-no-macro returns ~nil~, which then propagates as the
return value of c-determine-limit.  The problem boils down to: why does
c-determine-limit-no-macro return ~nil~?

The arguments passed to the function c-determine-limit-no-macro in the
offending invocation are non-nil.  That function is simple enough to
analyze with the naked eye, and it seems logically impossible for it to
return nil on non-nil arguments.  When I tried debugging it, the issue went
away entirely -- after instrumentation, c-determine-limit-no-macro returns
a numerical value, as it should, which propagates to a numerical return
value of c-determine-limit, and hence to an error-free execution of
c-guess-basic-syntax.  This is all with emacs -Q and tested repeatedly
across fresh startups of emacs.  I then tried simply C-M-x'ing
c-determine-limit-no-macro on startup, and the original issue went away.

As a "fix", I've simply copied the definition of c-determine-limit-no-macro
to my init file.  I'd still be happy to understand better what's going on.

Thanks, best,

Paul


On Sun, May 2, 2021 at 5:01 PM Alan Mackenzie <acm@muc.de> wrote:

> Hello, Basil.
>
> On Sun, May 02, 2021 at 14:33:29 +0100, Basil L. Contovounesios wrote:
> > Alan Mackenzie <acm@muc.de> writes:
>
> > >> Incidentally, "C-u C-M-x" applied to c-guess-basic-syntax gives a
> long and
> > >> complicated backtrace that starts with:
>
> > >> Debugger entered--Lisp error: (invalid-read-syntax "Expected"
> "lambda")
> > >>   edebug-syntax-error("Expected" "lambda")
>
> > > That, I can reproduce.  After a bit of experimentation, it would appear
> > > that this is due to the lack of an edebug-spec for the macro
> > > c-save-buffer-state.
>
> > Or rather, a recent change in its Edebug spec.
>
> > > To confirm this in the most basic manner, type
>
> > >    M-: (def-edebug-spec c-save-buffer-state let*)
>
> > Until recently, the Edebug spec of c-save-buffer-state was set twice:
> > once by its declare form (as 't'), and later by def-edebug-spec (as
> > 'let*').  The latter was recently removed:
>
> > CC Mode: Put debug specs inside declare forms.  Add missing debug specs.
> > 31f8ae53be 2021-04-15 10:11:20 +0000
> >
> https://git.sv.gnu.org/cgit/emacs.git/commit/?id=31f8ae53beb9bada58750160c1bf7f867ecd442e
>
> > This suggests that the remaining declare form is at fault.
>
> Thank you indeed for clearing this up.  The standalone CC Mode version
> was actually OK here, which made it harder to find.
>
> I think I'm still right about not being able to instrument
> c-guess-basic-syntax and friends until the correct debug spec has been
> loaded.  But who's going to be doing that, anyway?
>
> I will correct this bug soon.
>
> Thank you again.
>
> > Thanks,
>
> > --
> > Basil
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>

[-- Attachment #2: Type: text/html, Size: 5524 bytes --]