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

Previous Next

Full log

Message #8 received at 78872 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: 78872 <at> debbugs.gnu.org
Cc: Mattias Engdegård <mattiase <at> acm.org>, acm <at> muc.de
Subject: Re: bug#78872: Byte compiler: warning message lacks line and column
 numbers.
Date: Fri, 27 Jun 2025 13:56:58 +0000

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 <at> muc.de>
> 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).

Previous Next

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