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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Mattias Engdegård <mattiase <at> acm.org>, 78872 <at> debbugs.gnu.org
Subject: bug#78872: Byte compiler: warning message lacks line and column numbers.
Date: Sat, 28 Jun 2025 15:35:04 -0400

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

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


        Stefan

Previous Next

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