GNU bug report logs - #78872
Byte compiler: warning message lacks line and column numbers.

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Alan Mackenzie <acm@HIDDEN>; dated Mon, 23 Jun 2025 12:27:06 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 78872 <at> debbugs.gnu.org:


Received: (at 78872) by debbugs.gnu.org; 30 Jun 2025 11:29:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 30 07:29:31 2025
Received: from localhost ([127.0.0.1]:41380 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uWChW-0004vv-EK
	for submit <at> debbugs.gnu.org; Mon, 30 Jun 2025 07:29:31 -0400
Received: from mail.muc.de ([193.149.48.3]:41024)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1uWChT-0004ur-Nf
 for 78872 <at> debbugs.gnu.org; Mon, 30 Jun 2025 07:29:28 -0400
Received: (qmail 93214 invoked by uid 3782); 30 Jun 2025 13:29:20 +0200
Received: from muc.de (pd953a2fb.dip0.t-ipconnect.de [217.83.162.251]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 30 Jun 2025 13:29:19 +0200
Received: (qmail 7338 invoked by uid 1000); 30 Jun 2025 11:29:19 -0000
Date: Mon, 30 Jun 2025 11:29:19 +0000
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#78872: Byte compiler: warning message lacks line and column
 numbers.
Message-ID: <aGJ1D_Pzq-lMv27G@HIDDEN>
References: <aFlHqOtB29wJH60e@HIDDEN> <aF6jKq68fUAaI5pW@HIDDEN>
 <jwvv7ofoew2.fsf-monnier+emacs@HIDDEN>
 <aGGl4UatzzCLfpHq@HIDDEN>
 <jwvikkdkh9z.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <jwvikkdkh9z.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 78872
Cc: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= <mattiase@HIDDEN>,
 78872 <at> debbugs.gnu.org, acm@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

Thanks for such a rapid and helpful reply.

On Mon, Jun 30, 2025 at 00:17:35 -0400, Stefan Monnier wrote:
> >> Why is it that the fallback doesn't work here?
> > I think it's because all the symbols up to a car/cdr/combination of 10
> > are lacking positions.  These symbols are generated by the
> > compiler or macro expander (more the latter, I think).

> See below.

> >> [ I don't understand where the above warning comes from, so I'm probably
> >>   missing something.  AFAICT the only place where
> >>   `font-lock-keyword-face` appears is within a `quote` so there's no
> >>   chance it will elicit such a warning (although it also deserves such
> >>   a warning, admittedly 🙂).  ]

> > By the time '(1 font-lock-keyword-place t) gets used by the byte-compile
> > inside c-make-font-lock-search-function, that quote has been evaluated
> > away.

> Aaahhhh!

The warning is correct, though.  That form needs to look like
    '(1 'font-lock-keyword-place t)
, and when it's written like that it works fine, using the symbol rather
than the obsolete variable for the face.

> I think that's the culprit: the code with the `font-lock-keyword-face`
> reference is generated by a function and passed to `byte-compile`.
> There can't be any sympos in it for that reason (we need to strip
> sympos before we pass any sexp to `eval`).

The need to strip SWPs is solely to prevent their leakage, as you
mention.  Emacs bootstraps quite happily without this stripping, though
there is surely some use of eval-when-compile where it wouldn't be so
happy.

> If we want good warnings with good location information, we need to
> replace the `c-make-font-lock-search-function` function (which
> internally calls `byte-compile`) with a macro (which doesn't call
> `byte-compile` but instead returns the corresponding code so it gets
> byte-compiled by "the outer compiler").

Yes, this would be the best way to go.

> [ I have a trivial patch to do that, but sadly it doesn't quite fit in
>   the margin so I'll leave it as an exercise for the reader.  ]

Your margin is narrow indeed.  I think all that would be needed would be
to replace defun with defmacro, and remove the (byte-compile ...) around
the bulk of the code.  But I haven't tried it out, yet.

> >> > I seems to me that counting the depth of search is here sub-optimal.
> >> No doubt.  I thought it was OK because of the fallback to
> >> `byte-compile-form-stack` and also because returning nil occasionally is
> >> just a fact of life: the form may fail to contain any sympos, after all.
> > But it happens for a very shallowly nested form, here.

> Actually, I think it happens here because the stack is empty in the
> inner `byte-compile` (it would have to consult the stack of the outer
> compiler, but the two compiler invocations don't know each other, so
> it's not that simple).

If I increase the depth limit of 10 to 14 or more, I get the position in
the warning - just the wrong position.  ;-(  I'll need to look into this
a bit more.

> > What's happening is that eval-when-compile is wrongly compiling its
> > argument, then evaluating it.  This compilation removes the symbols'
> > positions, so they are no longer available when
> > c-make-font-lock-search-function's byte-compile runs.

> The symbols' positions have to be removed before we can run the code,
> regardless if we compile the code or not, otherwise sympos can "leak"
> outside their compilation.

Yes, this is the bit I missed yesterday.

> > Interestingly enough, eval-AND-compile _doesn't_ compile its argument.
> > It just macro-expands it, then both evaluates the result of the
> > expansion, and returns it.

> But the inner `byte-compile` would give a similarly poor location info
> in the warning because `eval-and-compile` also strips the sympos before
> evaluating the code.

Yes, it strips the SWPs before passing the code to eval, but leaves them
on for the "-and-compile" bit.

So perhaps the best thing to do is add a warning to the documentation of
byte-compile not to use it inside eval-when/and-compile, but instead to
prefer a macro.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78872; Package emacs. Full text available.

Message received at 78872 <at> debbugs.gnu.org:


Received: (at 78872) by debbugs.gnu.org; 30 Jun 2025 04:17:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 30 00:17:46 2025
Received: from localhost ([127.0.0.1]:35627 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uW5xi-0007bh-8L
	for submit <at> debbugs.gnu.org; Mon, 30 Jun 2025 00:17:46 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19258)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
 id 1uW5xf-0007aX-FE
 for 78872 <at> debbugs.gnu.org; Mon, 30 Jun 2025 00:17:44 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 75A8910025E;
 Mon, 30 Jun 2025 00:17:37 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1751257056;
 bh=Apj1owCM9FZEC091y+xPpGGKJKDIcQIkVCl+hiubYoA=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=Adp5qGpjDHw78BRqDG+kag46vIj4f5zURJhY6q20bgdz4jRopaKLPUEPKq+O7KaSg
 3UXZWqUwkV4Y8Kk/StnSu36x3tHtv2MWpvsFanBQUfBq+GaJjAp1F2+kj1GwzKkByp
 I7bZ1rsWlHcTzNn5p2y8yffY9dnyq/DzEoM2s/dMKvi72JSqxQgFDUF+U9UJw2RkRG
 WfcSNjUnZzW2wzgyAPh3qUpfMNjJBsix4wQB8mFMd+y13ozHUZa1layFyXsyb+YDf6
 T36bl912sXhDQyu3ayPbkEP63i6a6lauLOgaDhlOzLra06kTc1t55XSQzyPlXKokZ9
 trooRUWuqE1UA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 646A81000BC;
 Mon, 30 Jun 2025 00:17:36 -0400 (EDT)
Received: from pastel (unknown [104.247.225.139])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3440E1206AC;
 Mon, 30 Jun 2025 00:17:36 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: Re: bug#78872: Byte compiler: warning message lacks line and column
 numbers.
In-Reply-To: <aGGl4UatzzCLfpHq@HIDDEN>
Message-ID: <jwvikkdkh9z.fsf-monnier+emacs@HIDDEN>
References: <aFlHqOtB29wJH60e@HIDDEN> <aF6jKq68fUAaI5pW@HIDDEN>
 <jwvv7ofoew2.fsf-monnier+emacs@HIDDEN>
 <aGGl4UatzzCLfpHq@HIDDEN>
Date: Mon, 30 Jun 2025 00:17:35 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.304 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78872
Cc: Mattias =?windows-1252?Q?Engdeg=E5rd?= <mattiase@HIDDEN>,
 78872 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> Why is it that the fallback doesn't work here?
> I think it's because all the symbols up to a car/cdr/combination of 10
> are lacking positions.  These symbols are generated by the
> compiler or macro expander (more the latter, I think).

See below.

>> [ I don't understand where the above warning comes from, so I'm probably
>>   missing something.  AFAICT the only place where
>>   `font-lock-keyword-face` appears is within a `quote` so there's no
>>   chance it will elicit such a warning (although it also deserves such
>>   a warning, admittedly =F0=9F=99=82).  ]
>
> By the time '(1 font-lock-keyword-place t) gets used by the byte-compile
> inside c-make-font-lock-search-function, that quote has been evaluated
> away.

Aaahhhh!

I think that's the culprit: the code with the `font-lock-keyword-face`
reference is generated by a function and passed to `byte-compile`.
There can't be any sympos in it for that reason (we need to strip
sympos before we pass any sexp to `eval`).

If we want good warnings with good location information, we need to
replace the `c-make-font-lock-search-function` function (which
internally calls `byte-compile`) with a macro (which doesn't call
`byte-compile` but instead returns the corresponding code so it gets
byte-compiled by "the outer compiler").
[ I have a trivial patch to do that, but sadly it doesn't quite fit in
  the margin so I'll leave it as an exercise for the reader.  ]

>> > I seems to me that counting the depth of search is here sub-optimal.
>> No doubt.  I thought it was OK because of the fallback to
>> `byte-compile-form-stack` and also because returning nil occasionally is
>> just a fact of life: the form may fail to contain any sympos, after all.
> But it happens for a very shallowly nested form, here.

Actually, I think it happens here because the stack is empty in the
inner `byte-compile` (it would have to consult the stack of the outer
compiler, but the two compiler invocations don't know each other, so
it's not that simple).

> What's happening is that eval-when-compile is wrongly compiling its
> argument, then evaluating it.  This compilation removes the symbols'
> positions, so they are no longer available when
> c-make-font-lock-search-function's byte-compile runs.

The symbols' positions have to be removed before we can run the code,
regardless if we compile the code or not, otherwise sympos can "leak"
outside their compilation.

> Interestingly enough, eval-AND-compile _doesn't_ compile its argument.
> It just macro-expands it, then both evaluates the result of the
> expansion, and returns it.

But the inner `byte-compile` would give a similarly poor location info
in the warning because `eval-and-compile` also strips the sympos before
evaluating the code.


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78872; Package emacs. Full text available.

Message received at 78872 <at> debbugs.gnu.org:


Received: (at 78872) by debbugs.gnu.org; 29 Jun 2025 20:45:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jun 29 16:45:35 2025
Received: from localhost ([127.0.0.1]:60329 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uVyu6-0001bx-TR
	for submit <at> debbugs.gnu.org; Sun, 29 Jun 2025 16:45:35 -0400
Received: from mail.muc.de ([193.149.48.3]:53791)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1uVyu2-0001bC-La
 for 78872 <at> debbugs.gnu.org; Sun, 29 Jun 2025 16:45:31 -0400
Received: (qmail 21084 invoked by uid 3782); 29 Jun 2025 22:45:22 +0200
Received: from muc.de (p4fe15ba1.dip0.t-ipconnect.de [79.225.91.161]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Sun, 29 Jun 2025 22:45:22 +0200
Received: (qmail 9882 invoked by uid 1000); 29 Jun 2025 20:45:21 -0000
Date: Sun, 29 Jun 2025 20:45:21 +0000
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#78872: Byte compiler: warning message lacks line and column
 numbers.
Message-ID: <aGGl4UatzzCLfpHq@HIDDEN>
References: <aFlHqOtB29wJH60e@HIDDEN> <aF6jKq68fUAaI5pW@HIDDEN>
 <jwvv7ofoew2.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <jwvv7ofoew2.fsf-monnier+emacs@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 78872
Cc: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= <mattiase@HIDDEN>,
 78872 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Stefan.

On Sat, Jun 28, 2025 at 15:35:04 -0400, Stefan Monnier wrote:
> Hi Alan,

> >> The fourth looks like:
> >> test-cc-awk.el: Warning: ‘font-lock-keyword-face’ is an obsolete variable
> >> (as of 31.1); use the quoted symbol instead: 'font-lock-keyword-face
> [...]
> > where a limit of 10 to the search depths in byte-compile-form-stack was
> > imposed to prevent an infinite loop in rare circumstances.  This was in
> > function byte-compile--first-symbol-with-pos.

> > It turns out 10 is far too small, the smallest integer for which a
> > position appears for test-cc-awk.el being 14.

> IIRC we look for position info first in the "relevant sexp" (the sexp
> passed to `byte-compile--first-symbol-with-pos`) and if that fails, then
> we fallback on the position info from the context
> (i.e. `byte-compile-form-stack`).

> Why is it that the fallback doesn't work here?

I think it's because all the symbols up to a car/cdr/combination of 10
are lacking positions.  These symbols are generated by the
compiler or macro expander (more the latter, I think).

> [ I don't understand where the above warning comes from, so I'm probably
>   missing something.  AFAICT the only place where
>   `font-lock-keyword-face` appears is within a `quote` so there's no
>   chance it will elicit such a warning (although it also deserves such
>   a warning, admittedly 🙂).  ]

By the time '(1 font-lock-keyword-place t) gets used by the byte-compile
inside c-make-font-lock-search-function, that quote has been evaluated
away.

> > I seems to me that counting the depth of search is here sub-optimal.

> No doubt.  I thought it was OK because of the fallback to
> `byte-compile-form-stack` and also because returning nil occasionally is
> just a fact of life: the form may fail to contain any sympos, after all.

But it happens for a very shallowly nested form, here.

> > The necessary maximum depth for a deeply nested form would exceed any
> > reasonable value we could come up with.  I suggest that the function be
> > reformulated to record conses in a hash table to detect any loops; this
> > has been done successfully for other lists where we need to detect
> > loops.

> No objection on my side.

I will do this work, soon.

> BTW, I get the impression that the larger the term (and thus, the harder
> we work to find a sympos inside of it), the higher the risk of that
> sympos not being The Right One.  It's probably not a big deal either
> way, tho, since we just don't have enough info to determine which sympos
> is The Right One anyway.

> > Incidentally, the position in the warning message which gets output is
> > wrong.  I will address this in another post or bug report.

> I promise I wrote the above before reading this part.  🙂

I've spent the weekend working out why that happens.  The position given
for the unquoted font-lock-keywords-face in

(defconst vr-foo
  (eval-when-compile
    `(
      (,(c-make-font-lock-search-function
         "^\\s *\\(func\\(tion\\)?\\)\\s +\\(\\(\\sw+\\(::\\sw+\\)?\\)\\s *\\)?\\(([^()]*)\\)?"
         '(1 font-lock-keyword-face t))))))

is that of the eval-when-compile symbol.  This is obviously bad.

c-make-font-lock-search-function contains an explicit byte-compile form,
and I think it is this that produces the warning message.

What's happening is that eval-when-compile is wrongly compiling its
argument, then evaluating it.  This compilation removes the symbols'
positions, so they are no longer available when
c-make-font-lock-search-function's byte-compile runs.

eval-when-compile should NOT compile its argument.  It should evaluate
it.  When I remove that compilation, I get the correct position for the
warning message about font-lock-keyword-face.

Interestingly enough, eval-AND-compile _doesn't_ compile its argument.
It just macro-expands it, then both evaluates the result of the
expansion, and returns it.  Presumably the caller ends up compiling it,
I'm not sure.

I think I will post on emacs-devel about fixing that obtrusive
compilation in eval-when-compile.  Other developers may have opinions
about it.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78872; Package emacs. Full text available.

Message received at 78872 <at> debbugs.gnu.org:


Received: (at 78872) by debbugs.gnu.org; 28 Jun 2025 19:35:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 28 15:35:15 2025
Received: from localhost ([127.0.0.1]:52134 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uVbKV-0007yg-4q
	for submit <at> debbugs.gnu.org; Sat, 28 Jun 2025 15:35:15 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48485)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
 id 1uVbKS-0007uX-G2
 for 78872 <at> debbugs.gnu.org; Sat, 28 Jun 2025 15:35:13 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C3B3780AE0;
 Sat, 28 Jun 2025 15:35:06 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1751139305;
 bh=3UPxs3Whfzzi4YVr88fciBZbLD/kcqh0LMU4UyiFSgA=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=UtWXxIB5vj17RHQEd7K4kWm0TmoTKV+ixvukhbdgJW4aTXZ8hmrUWhJZysBzphPBR
 GNS79eKxfekbbEaDDAopCqfJzmkdgX474GUMsS1sk9cJy/MoOGHmozdkwOVLv+LroO
 TE54uI0h5UQkWCspTVSyt7EIog7zKJFq434FjSoEiuEXr/jvmJ7pCIaVL0coPBeZ6n
 cKzYjxnVl+FIXw+bV5sGT+OEuarg5LEnHR0lzWZp1LhyTZHF6a0cYruaH9wEvKHsBH
 PM2BjtEkVgEHH0ubzgGhybHeRlOlZ26BOJxuwsMeTvGKwAZ8cczNvcVZO9KgQBe1kI
 2n5BDcftJDKWQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C879B809C2;
 Sat, 28 Jun 2025 15:35:05 -0400 (EDT)
Received: from pastel (unknown [104.247.225.139])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 96BEC120609;
 Sat, 28 Jun 2025 15:35:05 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: Re: bug#78872: Byte compiler: warning message lacks line and column
 numbers.
In-Reply-To: <aF6jKq68fUAaI5pW@HIDDEN>
Message-ID: <jwvv7ofoew2.fsf-monnier+emacs@HIDDEN>
References: <aFlHqOtB29wJH60e@HIDDEN> <aF6jKq68fUAaI5pW@HIDDEN>
Date: Sat, 28 Jun 2025 15:35:04 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.308 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78872
Cc: Mattias =?windows-1252?Q?Engdeg=E5rd?= <mattiase@HIDDEN>,
 78872 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Hi Alan,

>> The fourth looks like:
>> test-cc-awk.el: Warning: =E2=80=98font-lock-keyword-face=E2=80=99 is an =
obsolete variable
>> (as of 31.1); use the quoted symbol instead: 'font-lock-keyword-face
[...]
> where a limit of 10 to the search depths in byte-compile-form-stack was
> imposed to prevent an infinite loop in rare circumstances.  This was in
> function byte-compile--first-symbol-with-pos.
>
> It turns out 10 is far too small, the smallest integer for which a
> position appears for test-cc-awk.el being 14.

IIRC we look for position info first in the "relevant sexp" (the sexp
passed to `byte-compile--first-symbol-with-pos`) and if that fails, then
we fallback on the position info from the context
(i.e. `byte-compile-form-stack`).

Why is it that the fallback doesn't work here?

[ I don't understand where the above warning comes from, so I'm probably
  missing something.  AFAICT the only place where
  `font-lock-keyword-face` appears is within a `quote` so there's no
  chance it will elicit such a warning (although it also deserves such
  a warning, admittedly =F0=9F=99=82).  ]

> I seems to me that counting the depth of search is here sub-optimal.

No doubt.  I thought it was OK because of the fallback to
`byte-compile-form-stack` and also because returning nil occasionally is
just a fact of life: the form may fail to contain any sympos, after all.

> The necessary maximum depth for a deeply nested form would exceed any
> reasonable value we could come up with.  I suggest that the function be
> reformulated to record conses in a hash table to detect any loops; this
> has been done successfully for other lists where we need to detect
> loops.

No objection on my side.

BTW, I get the impression that the larger the term (and thus, the harder
we work to find a sympos inside of it), the higher the risk of that
sympos not being The Right One.  It's probably not a big deal either
way, tho, since we just don't have enough info to determine which sympos
is The Right One anyway.

> Incidentally, the position in the warning message which gets output is
> wrong.  I will address this in another post or bug report.

I promise I wrote the above before reading this part.  =F0=9F=99=82


        Stefan





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78872; Package emacs. Full text available.

Message received at 78872 <at> debbugs.gnu.org:


Received: (at 78872) by debbugs.gnu.org; 27 Jun 2025 13:57:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 27 09:57:11 2025
Received: from localhost ([127.0.0.1]:37379 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uV9Zn-0005lQ-3c
	for submit <at> debbugs.gnu.org; Fri, 27 Jun 2025 09:57:11 -0400
Received: from mail.muc.de ([193.149.48.3]:54394)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1uV9Zj-0005js-8u
 for 78872 <at> debbugs.gnu.org; Fri, 27 Jun 2025 09:57:08 -0400
Received: (qmail 81320 invoked by uid 3782); 27 Jun 2025 15:56:59 +0200
Received: from muc.de (pd953ad89.dip0.t-ipconnect.de [217.83.173.137]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Fri, 27 Jun 2025 15:56:59 +0200
Received: (qmail 7374 invoked by uid 1000); 27 Jun 2025 13:56:58 -0000
Date: Fri, 27 Jun 2025 13:56:58 +0000
To: 78872 <at> debbugs.gnu.org
Subject: Re: bug#78872: Byte compiler: warning message lacks line and column
 numbers.
Message-ID: <aF6jKq68fUAaI5pW@HIDDEN>
References: <aFlHqOtB29wJH60e@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <aFlHqOtB29wJH60e@HIDDEN>
X-Debbugs-Cc: Stefan Monnier <monnier@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 78872
Cc: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= <mattiase@HIDDEN>, acm@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, also Stefan.

On Mon, Jun 23, 2025 at 12:25:12 +0000, Alan Mackenzie wrote:
> Hello, Mattias and Emacs.

> On the master branch at this commit:

> commit 1a8e8203a158f6bdc74e38f2cdb3214b6c06b9d8 (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Alan Mackenzie <acm@HIDDEN>
> Date:   Fri Jun 20 21:13:45 2025 +0000

>     CC Mode: Remove workarounds for missing "\_<", "\_>" in XEmacs

> ..

> With the attached file, at the command line in GNU/Linux, do:

> $ cd .../path/to/emacs/lisp/progmodes
> $ <Extract test-cc-awk.el to this directory.>
> $ .../path/to/emacs/src/emacs -Q -batch -f batch-byte-compile test-cc-awk.el

> ..  This gives four warning messages, three of which are just artifacts
> of the extraction of the test file.

> The fourth looks like:

> test-cc-awk.el: Warning: ‘font-lock-keyword-face’ is an obsolete variable (as of 31.1); use the quoted symbol instead: 'font-lock-keyword-face

> ..  This message has no line and column numbers indicating where the
> warning was detected.  This is a bug.

> Mattias, could you look at this, please.

> Thanks!

I've bisected the repository to find the place where this bug arose, and
it turns out it was the fix to

  bug#58601: 29.0.50; Infinite loop in byte-compile--first-symbol-with-pos

where a limit of 10 to the search depths in byte-compile-form-stack was
imposed to prevent an infinite loop in rare circumstances.  This was in
function byte-compile--first-symbol-with-pos.

It turns out 10 is far too small, the smallest integer for which a
position appears for test-cc-awk.el being 14.

I seems to me that counting the depth of search is here sub-optimal.
The necessary maximum depth for a deeply nested form would exceed any
reasonable value we could come up with.  I suggest that the function be
reformulated to record conses in a hash table to detect any loops; this
has been done successfully for other lists where we need to detect
loops.

I will implement this in the next few days if I don't hear objections
from others.

Incidentally, the position in the warning message which gets output is
wrong.  I will address this in another post or bug report.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to monnier@HIDDEN, bug-gnu-emacs@HIDDEN:
bug#78872; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 23 Jun 2025 12:26:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 23 08:26:17 2025
Received: from localhost ([127.0.0.1]:54927 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTgFX-0003Z2-Br
	for submit <at> debbugs.gnu.org; Mon, 23 Jun 2025 08:26:17 -0400
Received: from lists.gnu.org ([2001:470:142::17]:36948)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1uTgFI-0003Ty-Bx
 for submit <at> debbugs.gnu.org; Mon, 23 Jun 2025 08:26:05 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acm@HIDDEN>) id 1uTgEv-00045z-SB
 for bug-gnu-emacs@HIDDEN; Mon, 23 Jun 2025 08:25:35 -0400
Received: from mail.muc.de ([193.149.48.3])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acm@HIDDEN>) id 1uTgEr-0001rp-RX
 for bug-gnu-emacs@HIDDEN; Mon, 23 Jun 2025 08:25:33 -0400
Received: (qmail 26933 invoked by uid 3782); 23 Jun 2025 14:25:13 +0200
Received: from muc.de (pd953a878.dip0.t-ipconnect.de [217.83.168.120]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 23 Jun 2025 14:25:12 +0200
Received: (qmail 6702 invoked by uid 1000); 23 Jun 2025 12:25:12 -0000
Date: Mon, 23 Jun 2025 12:25:12 +0000
To: bug-gnu-emacs@HIDDEN
Subject: Byte compiler: warning message lacks line and column numbers.
Message-ID: <aFlHqOtB29wJH60e@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="Vuhne+egCHJGIGVl"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Debbugs-Cc: Mattias =?iso-8859-1?Q?Engdeg=E5r?= =?iso-8859-1?Q?d?=
 <mattiase@HIDDEN>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@HIDDEN;
 helo=mail.muc.de
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9,
 RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.1 (/)


--Vuhne+egCHJGIGVl
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Hello, Mattias and Emacs.

On the master branch at this commit:

commit 1a8e8203a158f6bdc74e38f2cdb3214b6c06b9d8 (HEAD -> master,
origin/master, origin/HEAD)
Author: Alan Mackenzie <acm@HIDDEN>
Date:   Fri Jun 20 21:13:45 2025 +0000

    CC Mode: Remove workarounds for missing "\_<", "\_>" in XEmacs

..

With the attached file, at the command line in GNU/Linux, do:

$ cd .../path/to/emacs/lisp/progmodes
$ <Extract test-cc-awk.el to this directory.>
$ .../path/to/emacs/src/emacs -Q -batch -f batch-byte-compile test-cc-awk.el

..  This gives four warning messages, three of which are just artifacts
of the extraction of the test file.

The fourth looks like:

test-cc-awk.el: Warning: ‘font-lock-keyword-face’ is an obsolete variable (as of 31.1); use the quoted symbol instead: 'font-lock-keyword-face

..  This message has no line and column numbers indicating where the
warning was detected.  This is a bug.

Mattias, could you look at this, please.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).


--Vuhne+egCHJGIGVl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="test-cc-awk.el"

;;; cc-awk.el --- AWK specific code within cc-mode. -*- lexical-binding: t -*-

;; Copyright (C) 1988, 1994, 1996, 2000, 2001, 2002, 2003, 2004, 2005,
;;   2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016,
;;   2017, 2018, 2019, 2020, 2021
;;   Free Software Foundation, Inc.

;; Author: Alan Mackenzie <acm@HIDDEN> (originally based on awk-mode.el)
;; Maintainer: FSF
;; Keywords: AWK, cc-mode, unix, languages

;; This file is part of GNU Emacs.

;; GNU Emacs is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 3, or (at your option)
;; any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, see
;; <http://www.gnu.org/licenses/>.

;;; Commentary:

;; This file contains (most of) the adaptations to cc-mode required for the
;; integration of AWK Mode.
;; It is organized thusly, the sections being separated by page breaks:
;;   1. The AWK Mode syntax table.
;;   2. Regular expressions for analyzing AWK code.
;;   3. Indentation calculation stuff ("c-awk-NL-prop text-property").
;;   4. Syntax-table property/font-locking stuff, including the
;;      font-lock-keywords setting.
;;   5. The AWK Mode before/after-change-functions.
;;   6. AWK Mode specific versions of commands like beginning-of-defun.
;; The AWK Mode keymap, abbreviation table, and the mode function itself are
;; in cc-mode.el.

;;; Code:

(eval-when-compile
  (let ((load-path
	 (if (and (boundp 'byte-compile-dest-file)
		  (stringp byte-compile-dest-file))
	     (cons (file-name-directory byte-compile-dest-file) load-path)
	   load-path)))
    (load "cc-bytecomp" nil t)))

(cc-require 'cc-defs)
(cc-require-when-compile 'cc-langs)
(cc-require-when-compile 'cc-fonts)
(cc-require 'cc-engine)

;; Awk regexps written with help from Peter Galbraith
;; <galbraith@HIDDEN>.
;; Take GNU Emacs's 'words out of the following regexp-opts.  They don't work
;; in XEmacs 21.4.4.  acm 2002/9/19.
(defconst awk-font-lock-keywords
  (eval-when-compile
    `(
      ;; Function declarations.
      (,(c-make-font-lock-search-function
	 "^\\s *\\(func\\(tion\\)?\\)\\s +\\(\\(\\sw+\\(::\\sw+\\)?\\)\\s *\\)?\\(([^()]*)\\)?"
	 '(1 font-lock-keyword-face t)
	 ;; We can't use LAXMATCH in `c-make-font-lock-search-function', so....
	 '((when (match-beginning 4)
	     (c-put-font-lock-face
	      (match-beginning 4) (match-end 4) 'font-lock-function-name-face)
	     nil))
	 ;; Put warning face on any use of :: inside the parens.
	 '((when (match-beginning 6)
	     (goto-char (1+ (match-beginning 6)))
	     (let ((end (1- (match-end 6))))
	       (while (and (< (point) end)
			   (c-syntactic-re-search-forward "::" end t))
		 (c-put-font-lock-face (- (point) 2) (point)
				       'font-lock-warning-face)))
	     nil))))

      ;; Variable names.
      ,(cons
	(regexp-opt
	 '("ARGC" "ARGIND" "ARGV" "BINMODE" "CONVFMT" "ENVIRON"
	   "ERRNO" "FIELDWIDTHS" "FILENAME" "FNR" "FPAT" "FS" "FUNCTAB"
	   "IGNORECASE" "LINT" "NF" "NR" "OFMT" "OFS" "ORS" "PREC"
	   "PROCINFO" "RLENGTH" "ROUNDMODE" "RS" "RSTART" "RT" "SUBSEP"
	   "SYNTAB" "TEXTDOMAIN")
	 'symbols)
	'font-lock-variable-name-face)

      ;; Special file names.  (acm, 2002/7/22)
      ;; The following regexp was created by first evaluating this in GNU Emacs 21.1:
      ;; (regexp-opt '("/dev/stdin" "/dev/stdout" "/dev/stderr" "/dev/fd/n" "/dev/pid"
      ;;			"/dev/ppid" "/dev/pgrpid" "/dev/user") 'words)
      ;; , removing the "?:" from each "\\(?:" (for backward compatibility with older Emacsen)
      ;; , replacing the "n" in "dev/fd/n" with "[0-9]+"
      ;; , removing the unwanted \\< at the beginning, and finally filling out the
      ;; regexp so that a " must come before, and either a " or heuristic stuff after.
      ;; The surrounding quotes are fontified along with the filename, since, semantically,
      ;; they are an indivisible unit.
      ("\\(\"/dev/\\(fd/[0-9]+\\|p\\(\\(\\(gr\\)?p\\)?id\\)\\|\
std\\(err\\|in\\|out\\)\\|user\\)\\)\\_>\
\\(\\(\"\\)\\|\\([^\"/\n\r][^\"\n\r]*\\)?$\\)"
       (1 'font-lock-variable-name-face t)
       (8 'font-lock-variable-name-face t t))
     ;; Do the same (almost) with
     ;; (regexp-opt '("/inet/tcp/lport/rhost/rport" "/inet/udp/lport/rhost/rport"
     ;;                 "/inet/raw/lport/rhost/rport") 'words) (Since adapted
     ;;                 to later GAWK versions).
     ;; This cannot be combined with the above pattern, because the match number
     ;; for the (optional) closing \" would then exceed 9.
     ("\\(\"/inet[46]?/\\(\\(raw\\|\\(tc\\|ud\\)p\\)/[[:alnum:]]+/[[:alnum:]]+/[[:alnum:]]+\\)\\)\\_>\
\\(\\(\"\\)\\|\\([^\"/\n\r][^\"\n\r]*\\)?$\\)"
       (1 'font-lock-variable-name-face t)
       (6 'font-lock-variable-name-face t t))

     ;; Keywords.
     ,(regexp-opt
       '("BEGIN" "BEGINFILE" "END" "ENDFILE"
	 "break" "case" "continue" "default" "delete"
	 "do" "else" "exit" "for" "getline" "if" "in" "next"
	 "nextfile" "return" "switch" "while")
       'symbols)

     ;; Builtins.
     (eval . (list
	      ,(regexp-opt
		'("adump" "and" "asort" "asorti" "atan2" "bindtextdomain" "close"
		  "compl" "cos" "dcgettext" "dcngettext" "exp" "extension" "fflush"
		  "gensub" "gsub" "index" "int" "isarray" "length" "log" "lshift"
		  "match" "mkbool" "mktime" "or" "patsplit" "print" "printf" "rand"
		  "rshift" "sin" "split" "sprintf" "sqrt" "srand" "stopme"
		  "strftime" "strtonum" "sub" "substr"  "system"
		  "systime" "tolower" "toupper" "typeof" "xor")
		'symbols)
	      0 c-preprocessor-face-name))

      ;; Directives
      (eval . '("@\\(include\\|load\\|namespace\\)\\_>" 0 ,c-preprocessor-face-name))

      ;; gawk debugging keywords.  (acm, 2002/7/21)
      ;; (Removed, 2003/6/6.  These functions are now fontified as built-ins)
      ;;	(list (concat "\\<" (regexp-opt '("adump" "stopme") t) "\\>")
      ;;	   0 'font-lock-warning-face)

      ;; User defined functions with an apparent spurious space before the
      ;; opening parenthesis.  acm, 2002/5/30.
      (,(concat "\\(\\w\\|_\\)" c-awk-escaped-nls* "\\s "
		c-awk-escaped-nls*-with-space* "(")
       (0 'font-lock-warning-face))

      ;; Double :: tokens, or the same with space(s) around them.
      c-awk-font-lock-invalid-namespace-separators

      ;; Space after \ in what looks like an escaped newline.  2002/5/31
      ("\\\\\\s +$" 0 'font-lock-warning-face t)

      ;; Unbalanced string (") or regexp (/) delimiters.  2002/02/16.
      ("\\s|" 0 'font-lock-warning-face t nil)
      ;; gawk 3.1 localizable strings ( _"translate me!").  2002/5/21
      ("\\(_\\)\\s|" 1 'font-lock-warning-face)
      ,@(unless (featurep 'xemacs)
	  '(("\\(_\\)\\s\"" 1 'font-lock-string-face)))
      ))
  "Default expressions to highlight in AWK mode.")

;;; Local Variables:
;;; indent-tabs-mode: t
;;; tab-width: 8
;;; End:
;;; cc-awk.el ends here

--Vuhne+egCHJGIGVl--




Acknowledgement sent to Alan Mackenzie <acm@HIDDEN>:
New bug report received and forwarded. Copy sent to mattiase@HIDDEN, bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to mattiase@HIDDEN, bug-gnu-emacs@HIDDEN:
bug#78872; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 30 Jun 2025 11:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.