bug#63302: 29.0.90; Native comp does not respect byte-compile-warnings

[Jimmy Yuen Ho Wong <wyuenho@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

Yes I'm talking about nativecomp.

Reproduction:

1. (setq package-native-compile t)
2. (setq byte-compile-warnings '(not docstrings
docstrings-non-ascii-quotes))
3. (setq native-comp-async-report-warnings-errors 'silent)
4. M-x package-install ov
5. Observe the differences between the *Compile-Log* buffer and the
*Warnings* buffer.


Jimmy


On Fri, May 5, 2023 at 2:22 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> > Date: Fri, 05 May 2023 12:51:47 +0100
> >
> >
> > `byte-compile-warnings` is commonly set to to remove `docstring` so
> > spurious `docstring wider than 80 characters` are removed.  When it is
> > set to such a way, normal byte compilation of a el file with a docstring
> > longer than 80 characters will not result in the above warning, but
> > natively compiling the same file will.
> >
> > The expectation should be that nativecomp respects this variable at the
> > very least, or that the linting capabilities is moved out of byte
> > compilation into a seperate package ala elisp-lint. A compiler should
> > compile any program that is valid without producing any warnings except
> > obsolete/deprecations.
>
> Please show a recipe for reproducing this warning from native
> compilation.
>
> I suspect that you are talking about JIT native-compilation, which
> happens in a separate Emacs process, in which case we need a way of
> injecting settings into that separate process to suppress warnings
> selectively, or for doing any other similar jobs.  Seeing a recipe for
> reproducing this will confirm or contradict my guess.
>
> Andrea, any comments?
>

[-- Attachment #2: Type: text/html, Size: 2310 bytes --]