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

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

[Jimmy Yuen Ho Wong]

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

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

[Eli Zaretskii]

> 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?

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

[Jimmy Yuen Ho Wong]

[-- 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 --]

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

[Andrea Corallo]

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

Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:

> 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

Hi Jimmy,

could you try the attached and report if it solves the reported issue?

Best Regards

  Andrea


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: warning.patch --]
[-- Type: text/x-diff, Size: 1123 bytes --]

diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
index 025d21631bb..d7a60b9f007 100644
--- a/lisp/emacs-lisp/comp.el
+++ b/lisp/emacs-lisp/comp.el
@@ -3732,6 +3732,7 @@ comp-final
                            ',native-comp-compiler-options
                            native-comp-driver-options
                            ',native-comp-driver-options
+                           byte-compile-warnings ',byte-compile-warnings
                            load-path ',load-path)
                      ,native-comp-async-env-modifier-form
                      (message "Compiling %s..." ',output)
@@ -4004,6 +4005,7 @@ comp-run-async-workers
                                              native-comp-driver-options
                                              load-path
                                              backtrace-line-length
+                                             byte-compile-warnings
                                              ;; package-load-list
                                              ;; package-user-dir
                                              ;; package-directory-list

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

[Jimmy Wong]

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

This works, thank you!
On 10 May 2023 at 12:53 PM +0100, Andrea Corallo <akrl@sdf.org>, wrote:
> Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
>
> > 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
>
> Hi Jimmy,
>
> could you try the attached and report if it solves the reported issue?
>
> Best Regards
>
> Andrea
>

[-- Attachment #2.1: Type: text/html, Size: 1255 bytes --]

[-- Attachment #2.2: warning.patch --]
[-- Type: application/octet-stream, Size: 1143 bytes --]

diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
index 025d21631bb..d7a60b9f007 100644
--- a/lisp/emacs-lisp/comp.el
+++ b/lisp/emacs-lisp/comp.el
@@ -3732,6 +3732,7 @@ comp-final
                            ',native-comp-compiler-options
                            native-comp-driver-options
                            ',native-comp-driver-options
+                           byte-compile-warnings ',byte-compile-warnings
                            load-path ',load-path)
                      ,native-comp-async-env-modifier-form
                      (message "Compiling %s..." ',output)
@@ -4004,6 +4005,7 @@ comp-run-async-workers
                                              native-comp-driver-options
                                              load-path
                                              backtrace-line-length
+                                             byte-compile-warnings
                                              ;; package-load-list
                                              ;; package-user-dir
                                              ;; package-directory-list

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

[Andrea Corallo]

Jimmy Wong <wyuenho@gmail.com> writes:

> This works, thank you!

Cool!

Eli do we want to have this into master or 29?

Best Regards

  Andrea

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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: 63302@debbugs.gnu.org, Jimmy Wong <wyuenho@gmail.com>
> Date: Wed, 17 May 2023 07:49:19 +0000
> 
> Jimmy Wong <wyuenho@gmail.com> writes:
> 
> > This works, thank you!
> 
> Cool!
> 
> Eli do we want to have this into master or 29?

Please install on emacs-29, and thanks.

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 63302@debbugs.gnu.org, Jimmy Wong <wyuenho@gmail.com>
>> Date: Wed, 17 May 2023 07:49:19 +0000
>> 
>> Jimmy Wong <wyuenho@gmail.com> writes:
>> 
>> > This works, thank you!
>> 
>> Cool!
>> 
>> Eli do we want to have this into master or 29?
>
> Please install on emacs-29, and thanks.

Done as 1e57b2b4c79, closing then.

Thanks

  Andrea

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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?

Hi Eli,

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

Will look at that and report.

  Andrea