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: 4022 bytes --]

Hi Alan,

Looks good after updating -- seems like it was indeed a repeat of #48061.
Thanks for your help!  I'll report back if anything similar comes up again.

Paul


On Wed, May 5, 2021 at 12:18 PM Alan Mackenzie <acm@muc.de> wrote:

> Hello, Paul.
>
> On Wed, May 05, 2021 at 05:01:36 +0200, Paul Nelson wrote:
> > 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).
>
> I'm glad you put so much work into debugging this.  What you have
> probably done is found bug #48061 again, which saves me a lot of work.
> Thanks!  ;-)
>
> In that bug, the native compiler mis-compiled c-determine-limit-no-macro
> such that it sometimes returned an invalid value nil.  This looks like
> exactly what we are seeing now.  Bug #48061 was fixed and closed on
> Wednesday 28th April, a week ago.
>
> Could I ask you, please, to update your Emacs (if you haven't already
> done so) and rebuild it.  With any luck, the current bug will have been
> fixed.  I'm leaving the rest of your last post here, just in case we
> don't yet have a fix.  Would you please let us know how your latest test
> goes.  Thanks!
>
> > 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
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>

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