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

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

[Paul Nelson]

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

Inserting a sufficiently large chunk of text into a fresh cpp file
breaks syntax highlighting and causes the buffer to enter a
semi-permanent broken state.  Moreover, the offending function
"c-guess-basic-syntax" seems to break edebug instrumentation.

In more detail:

Start from emacs -Q.  Insert sufficiently many lines of C++ code in a
temporary buffer.  A slightly contrived example:

#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <climits>
#include <cfloat>
#include <vector>
#include <cmath>
#include <set>
#include <list>
#include <map>
#include <stack>
#include <queue>
#include <iostream>
#include <sstream>
#include <fstream>
#include <algorithm>
#include <numeric>
#include <functional>
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <climits>
#include <cfloat>
#include <vector>
#include <cmath>
#include <set>
#include <list>
#include <map>
#include <stack>

Copy these lines to the kill ring.  Create a new file "test.cpp", and
paste what was copied.

The first error is that syntax highlighting stops after a certain
number of lines (in the above example, just before the final line).

The same problem arises if such lines are inserted via abbrev-mode.
This is the intended use case.

No problem if such lines are copy/pasted in small enough chunks.

The problem *appears* to go away if one cuts and then pastes the
offending lines, but the buffer remains in a broken state.  For
instance, attempting to insert a couple newlines followed by
  int main(
gives the following error:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  c-guess-basic-syntax()
  c-indent-line()
  indent-according-to-mode()
  c-electric-paren(nil)
  funcall-interactively(c-electric-paren nil)
  command-execute(c-electric-paren)

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")

---


In GNU Emacs 28.0.50 (build 2, x86_64-apple-darwin19.6.0, NS appkit-1894.60
Version 10.15.7 (Build 19H524))
 of 2021-04-26 built on Pauls-MBP-2
Repository revision: 9d34fd8b33c55768190d41239931120e3fc9717f
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.7

Configured using:
 'configure --with-native-compilation'

Configured features:
ACL DBUS GMP GNUTLS JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY KQUEUE
NS PDUMPER PNG THREADS TIFF TOOLKIT_SCROLL_BARS XIM ZLIB

Important settings:
  value of $LC_CTYPE: UTF-8
  value of $LANG: en_CH.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C++//l

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs
password-cache json map text-property-search time-date mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils novice
comp comp-cstr warnings subr-x rx cl-seq cl-macs cl-extra help-mode seq
byte-opt gv bytecomp byte-compile cconv cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
cl-loaddefs cl-lib iso-transl tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind kqueue cocoa ns
lcms2 multi-tty make-network-process nativecomp emacs)

Memory information:
((conses 16 126796 8572)
 (symbols 48 11546 0)
 (strings 32 31421 1656)
 (string-bytes 1 1165707)
 (vectors 16 18464)
 (vector-slots 8 333103 10770)
 (floats 8 30 33)
 (intervals 56 540 0)
 (buffers 992 14))

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

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

[Lars Ingebrigtsen]

Paul Nelson <ultrono@gmail.com> writes:

> Start from emacs -Q.  Insert sufficiently many lines of C++ code in a
> temporary buffer.  A slightly contrived example:

[...]

> Copy these lines to the kill ring.  Create a new file "test.cpp", and
> paste what was copied.
>
> The first error is that syntax highlighting stops after a certain
> number of lines (in the above example, just before the final line).

I tried this in Emacs 28, and I could not reproduce the reported
behaviour -- this works fine for me.

> 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")

I can reproduce this, though, so I've added Alan to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Alan Mackenzie]

Hello, Paul and Lars.

On Thu, Apr 29, 2021 at 10:04:36 +0200, Paul Nelson wrote:
> Inserting a sufficiently large chunk of text into a fresh cpp file
> breaks syntax highlighting and causes the buffer to enter a
> semi-permanent broken state.  Moreover, the offending function
> "c-guess-basic-syntax" seems to break edebug instrumentation.

Thanks for taking the trouble to report these bugs.

> In more detail:

> Start from emacs -Q.  Insert sufficiently many lines of C++ code in a
> temporary buffer.  A slightly contrived example:

> #include <cstdio>
> #include <cstdlib>
> #include <cstring>
> #include <climits>
> #include <cfloat>
> #include <vector>
> #include <cmath>
> #include <set>
> #include <list>
> #include <map>
> #include <stack>
> #include <queue>
> #include <iostream>
> #include <sstream>
> #include <fstream>
> #include <algorithm>
> #include <numeric>
> #include <functional>
> #include <cstdio>
> #include <cstdlib>
> #include <cstring>
> #include <climits>
> #include <cfloat>
> #include <vector>
> #include <cmath>
> #include <set>
> #include <list>
> #include <map>
> #include <stack>

> Copy these lines to the kill ring.  Create a new file "test.cpp", and
> paste what was copied.

I'm assuming here that by "paste" you mean type C-y.

> The first error is that syntax highlighting stops after a certain
> number of lines (in the above example, just before the final line).

I can't reproduce this, that's on GNU/Linux, neither in a tty nor in
X-Windows.

However, it looks like on your machine Emacs is fontifying one single
500-byte chunk (which is rounded up to the next EOL) and then neglecting
the rest of the lines input (i.e. the final line with <stack>).

> The same problem arises if such lines are inserted via abbrev-mode.
> This is the intended use case.

> No problem if such lines are copy/pasted in small enough chunks.

> The problem *appears* to go away if one cuts and then pastes the
> offending lines, but the buffer remains in a broken state.  For
> instance, attempting to insert a couple newlines followed by
>   int main(
> gives the following error:

> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   c-guess-basic-syntax()
>   c-indent-line()
>   indent-according-to-mode()
>   c-electric-paren(nil)
>   funcall-interactively(c-electric-paren nil)
>   command-execute(c-electric-paren)

I can't reproduce that either, I'm afraid.  At least, not yet.

> 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.  To confirm this in the most basic manner, type

   M-: (def-edebug-spec c-save-buffer-state let*)

, after which C-u C-M-x works on c-guess-basic-syntax.  More
practically, this situation can be worked around with

  M-x load-library RET cc-mode RET

, which loads cc-defs.elc, which contains the pertinent edebug-spec.  I
don't understand how that edebug-spec in cc-defs.elc is not loaded
anyway, given the you're already using CC Mode.  Perhaps that will
become clearer in the next few days.

> In GNU Emacs 28.0.50 (build 2, x86_64-apple-darwin19.6.0, NS appkit-1894.60
> Version 10.15.7 (Build 19H524))
>  of 2021-04-26 built on Pauls-MBP-2
> Repository revision: 9d34fd8b33c55768190d41239931120e3fc9717f
> Repository branch: master
> Windowing system distributor 'Apple', version 10.3.1894
> System Description:  Mac OS X 10.15.7

> Configured using:
>  'configure --with-native-compilation'

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Basil L. Contovounesios]

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.

Thanks,

-- 
Basil

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

[Alan Mackenzie]

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).

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

[Paul Nelson]

[-- 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 --]

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

[Lars Ingebrigtsen]

Paul Nelson <ultrono@gmail.com> writes:

> I then tried simply C-M-x'ing c-determine-limit-no-macro on startup,
> and the original issue went away.

It sound like your Emacs might be miscompiled.  Have you tried doing a
"make bootstrap"?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Alan Mackenzie]

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).

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

[Paul Nelson]

[-- 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 --]

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

[Alan Mackenzie]

close 48100
merge 48061 48100
quit

Hello, Paul.

On Thu, May 06, 2021 at 12:26:12 +0200, Paul Nelson wrote:
> 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.

Thanks, I'm glad it's fixed.  I'm closing the bug with this post, and
trying to merge it into bug #48061, the first bug where
c-determine-limit-no-macro miscompiled.

> Paul

-- 
Alan Mackenzie (Nuremberg, Germany).