bug#78872: Byte compiler: warning message lacks line and column numbers.

[Alan Mackenzie]

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