GNU bug report logs - #63302
29.0.90; Native comp does not respect byte-compile-warnings

Previous Next

Full log

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>, 63302 <at> debbugs.gnu.org
Subject: Re: bug#63302: 29.0.90; Native comp does not respect
 byte-compile-warnings
Date: Wed, 10 May 2023 09:57:53 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Jimmy Yuen Ho Wong <wyuenho <at> 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?

Hi Eli,

yep, I guess we probably have to just forward the variable to the
spawned processes.

Will look at that and report.

  Andrea

Previous Next

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