From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Nelson Newsgroups: gmane.emacs.bugs Subject: bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer Date: Wed, 5 May 2021 05:01:36 +0200 Message-ID: References: <87a6pd45w6.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005ed33f05c18c6ad7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7148"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Basil L. Contovounesios" , Lars Ingebrigtsen , 48100@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 05 09:42:56 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1leCBM-0001kZ-Gg for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 May 2021 09:42:56 +0200 Original-Received: from localhost ([::1]:56866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1leCBL-0000yy-Hv for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 May 2021 03:42:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53516) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1leC9W-00076Y-LM for bug-gnu-emacs@gnu.org; Wed, 05 May 2021 03:41:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46771) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1leC9W-000562-Br for bug-gnu-emacs@gnu.org; Wed, 05 May 2021 03:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1leC9W-0004kP-9l for bug-gnu-emacs@gnu.org; Wed, 05 May 2021 03:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Nelson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 May 2021 07:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48100 X-GNU-PR-Package: emacs Original-Received: via spool by 48100-submit@debbugs.gnu.org id=B48100.162020040418221 (code B ref 48100); Wed, 05 May 2021 07:41:02 +0000 Original-Received: (at 48100) by debbugs.gnu.org; 5 May 2021 07:40:04 +0000 Original-Received: from localhost ([127.0.0.1]:58313 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1leC8Y-0004jm-A3 for submit@debbugs.gnu.org; Wed, 05 May 2021 03:40:04 -0400 Original-Received: from mail-pj1-f49.google.com ([209.85.216.49]:50978) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1le7nN-0005pT-SQ for 48100@debbugs.gnu.org; Tue, 04 May 2021 23:01:54 -0400 Original-Received: by mail-pj1-f49.google.com with SMTP id md17so62021pjb.0 for <48100@debbugs.gnu.org>; Tue, 04 May 2021 20:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cZxjmeJ6tFyPhxs1nwTVYTOTCkS2rRiFyxhVCo1hk+8=; b=W4q4B4/CjmfofS0sRTthNDjlRJlC6jsh8PSYl3Fa8VjHClzTAwIBPdL5L6j/SUiXGB 1tNJgRcRMpF2zVKIsX3FmNXZ/yUYTM6iEfNuffoz9ROBlUbHEa/nLitXlNEZ1znXzbgi PW+nWOVbtweKKA/lmvOkD8WlnhS3YvPAHHM1k8GoNRes+UVT1u6MQwll1HTYbkcWihUQ mSTtSTuIpUnptDNzxCT9alA6C4H/iA1tdoIr4aySg1oimpU0g78+0IRQbnryWlQmlUU0 aTmcN8Y2kAy9bRhlYvom55lp70gVqlK3vE+wCsvLXgSSl927Rr9NJqSH0WRNarE8UTWe a8wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cZxjmeJ6tFyPhxs1nwTVYTOTCkS2rRiFyxhVCo1hk+8=; b=kbXAz8kLd6qP1urDZU0yAhXjIhqXihH++HVE4YevrWenNa4V8hA5oD/1zoLaBkkgWJ sG5AYpWnQGjeIBHzr7mJ3P9e5pRRul8J727Zoo/Y1VBArN1SvaGTFayggzb0MwxwmI2e bwoccUV36TIu3ntx8lapN3YVNlqCI9Ra03GPtcTorV/0N2eHtesWSSWM1dKVbNLnOILM NTYt8AbbjgcuKwfQ8OOSY5mV3K8fKDTJ0Digvrind5uWxasTZcZyKkxMcauIiHTOsKRm ch9XoLbVbdH2itrsxTzeSaMcJtT5kBUpgeK7Y8UPJQ79DEv4UTKE5IRXY6VZwM3MyWx8 VZVA== X-Gm-Message-State: AOAM531pFQCKgg0Gj3rYN0E9umr7fAgqLYKT2OJewzXFwlyvBsLNZuNJ xkRhuGBMpb0SXfClq7HP6tBouqg0QU8GJVEra/0= X-Google-Smtp-Source: ABdhPJwZQNTTuD7EDsW6pe1JF9VBGysz05MTqoo8JYOGQJDylfKzG5RKEJSj7M2Lnbccf7eeSH0CaOTWWypagsGwkUQ= X-Received: by 2002:a17:90b:347:: with SMTP id fh7mr8946857pjb.183.1620183707733; Tue, 04 May 2021 20:01:47 -0700 (PDT) In-Reply-To: X-Mailman-Approved-At: Wed, 05 May 2021 03:40:01 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:205661 Archived-At: --0000000000005ed33f05c18c6ad7 Content-Type: text/plain; charset="UTF-8" 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 wrote: > Hello, Basil. > > On Sun, May 02, 2021 at 14:33:29 +0100, Basil L. Contovounesios wrote: > > Alan Mackenzie 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). > --0000000000005ed33f05c18c6ad7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

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

In summary, the i= ssue goes away entirely if I simply C-M-x the function c-determine-limit-no= -macro before doing anything.=C2=A0 What baffles me is why that function sh= ould behave differently after C-M-x'ing (perhaps something to do with e= macs 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 isol= ated peculiarity related to inserting large chunks of code -- the same bug = has shown up repeatedly the past few days in more "organic" situa= tions involving normal C++ code.=C2=A0 The example noted in my original rep= ort remains the simplest reproducible one that I've found.

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

=C2=A0 ;; CAS= E 5B: After a function header but before the body (or
;; the ending semi= colon if there's no body).
((save-excursion
=C2=A0 =C2=A0(when (s= etq placeholder (c-just-after-func-arglist-p
=C2=A0 =C2=A0 (max lim (c-d= etermine-limit 500))))
=C2=A0 =C2=A0 =C2=A0(setq tmp-pos (point))))
= =C2=A0(cond

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

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

((>=3D count how-far-back)
=C2=A0(c-determine-limit-no-macro<= br>=C2=A0(+ (car elt) (- count how-far-back))
=C2=A0org-start))

S= tepping through the above code block in edebug using SPC, the function c-de= termine-limit-no-macro returns ~nil~, which then propagates as the return v= alue of c-determine-limit.=C2=A0 The problem boils down to: why does c-dete= rmine-limit-no-macro return ~nil~?

The arguments passed to the funct= ion c-determine-limit-no-macro in the offending invocation are non-nil.=C2= =A0 That function is simple enough to analyze with the naked eye, and it se= ems logically impossible for it to return nil on non-nil arguments.=C2=A0 W= hen I tried debugging it, the issue went away entirely -- after instrumenta= tion, c-determine-limit-no-macro returns a numerical value, as it should, w= hich propagates to a numerical return value of c-determine-limit, and hence= to an error-free execution of c-guess-basic-syntax.=C2=A0 This is all with= emacs -Q and tested repeatedly across fresh startups of emacs.=C2=A0 I the= n 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 cop= ied the definition of c-determine-limit-no-macro to my init file.=C2=A0 I&#= 39;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&= gt; 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 "Expe= cted" "lambda")
> >>=C2=A0 =C2=A0edebug-syntax-error("Expected" "la= mbda")

> > That, I can reproduce.=C2=A0 After a bit of experimentation, it w= ould 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

> >=C2=A0 =C2=A0 M-: (def-edebug-spec c-save-buffer-state let*)

> Until recently, the Edebug spec of c-save-buffer-state was set twice:<= br> > once by its declare form (as 't'), and later by def-edebug-spe= c (as
> 'let*').=C2=A0 The latter was recently removed:

> CC Mode: Put debug specs inside declare forms.=C2=A0 Add missing debug= specs.
> 31f8ae53be 2021-04-15 10:11:20 +0000
> http= s://git.sv.gnu.org/cgit/emacs.git/commit/?id=3D31f8ae53beb9bada58750160c1bf= 7f867ecd442e

> This suggests that the remaining declare form is at fault.

Thank you indeed for clearing this up.=C2=A0 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.=C2=A0 But who's going to be doing that, anyway?

I will correct this bug soon.

Thank you again.

> Thanks,

> --
> Basil

--
Alan Mackenzie (Nuremberg, Germany).
--0000000000005ed33f05c18c6ad7--