native-comp-async-report-warnings-errors default value

native-comp-async-report-warnings-errors default value

[Robert Pluim]

I just built emacs-28 --with-native-compilation, started up Emacs, and
then watched aghast as it spewed hundreds of warnings whilst native
compiling, preventing me from getting anything useful done for quite
some time.

Can we default this to `silent'?

Robert
-- 

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Thu, 14 Oct 2021 13:23:44 +0200
> 
> I just built emacs-28 --with-native-compilation, started up Emacs, and
> then watched aghast as it spewed hundreds of warnings whilst native
> compiling, preventing me from getting anything useful done for quite
> some time.
> 
> Can we default this to `silent'?

No, not yet: too many problems that trigger those warnings need to be
fixed rather than swept under the carpet of silence.  But you can do
it in your customizations if you don't want to be bothered.

Re: native-comp-async-report-warnings-errors default value

[Robert Pluim]

>>>>> On Thu, 14 Oct 2021 14:30:45 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Thu, 14 Oct 2021 13:23:44 +0200
    >> 
    >> I just built emacs-28 --with-native-compilation, started up Emacs, and
    >> then watched aghast as it spewed hundreds of warnings whilst native
    >> compiling, preventing me from getting anything useful done for quite
    >> some time.
    >> 
    >> Can we default this to `silent'?

    Eli> No, not yet: too many problems that trigger those warnings need to be
    Eli> fixed rather than swept under the carpet of silence.  But you can do
    Eli> it in your customizations if you don't want to be bothered.

As long as we do it just before we release emacs-28, I guess thatʼs
OK.

Robert
-- 

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 14 Oct 2021 13:43:32 +0200
> 
> >>>>> On Thu, 14 Oct 2021 14:30:45 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim@gmail.com>
>     >> Date: Thu, 14 Oct 2021 13:23:44 +0200
>     >> 
>     >> I just built emacs-28 --with-native-compilation, started up Emacs, and
>     >> then watched aghast as it spewed hundreds of warnings whilst native
>     >> compiling, preventing me from getting anything useful done for quite
>     >> some time.
>     >> 
>     >> Can we default this to `silent'?
> 
>     Eli> No, not yet: too many problems that trigger those warnings need to be
>     Eli> fixed rather than swept under the carpet of silence.  But you can do
>     Eli> it in your customizations if you don't want to be bothered.
> 
> As long as we do it just before we release emacs-28, I guess thatʼs
> OK.

Please report the warnings, if they are in core files.

Re: native-comp-async-report-warnings-errors default value

[Stefan Kangas]

Robert Pluim <rpluim@gmail.com> writes:

> As long as we do it just before we release emacs-28, I guess thatʼs
> OK.

Indeed.  These warnings make Emacs rather unusable for a while after
start if you have many packages.

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 14 Oct 2021 05:07:42 -0700
> Cc: emacs-devel@gnu.org
> 
> Robert Pluim <rpluim@gmail.com> writes:
> 
> > As long as we do it just before we release emacs-28, I guess thatʼs
> > OK.
> 
> Indeed.  These warnings make Emacs rather unusable for a while after
> start if you have many packages.

You can facilitate the solution by reporting those warnings more
eagerly.

Re: native-comp-async-report-warnings-errors default value

[Robert Pluim]

>>>>> On Thu, 14 Oct 2021 14:52:32 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> As long as we do it just before we release emacs-28, I guess thatʼs
    >> OK.

    Eli> Please report the warnings, if they are in core files.

Theyʼre all in packages, so far. Although one of those is org, so
perhaps I should switch back to the in-tree version for a while.

Robert
-- 

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 14 Oct 2021 16:48:31 +0200
> 
> >>>>> On Thu, 14 Oct 2021 14:52:32 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> As long as we do it just before we release emacs-28, I guess thatʼs
>     >> OK.
> 
>     Eli> Please report the warnings, if they are in core files.
> 
> Theyʼre all in packages, so far.

Those should be reported to the corresponding developers.

> Although one of those is org, so perhaps I should switch back to the
> in-tree version for a while.

Is your current version newer than the one on emacs-28?  If so, I
think the warnings should be reported to Org developers.

Re: native-comp-async-report-warnings-errors default value

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Theyʼre all in packages, so far.
>
> Those should be reported to the corresponding developers.

Having compilation warnings in packages is very normal (and is because
the packages target a wide range of Emacs versions).  I don't think it's
a productive use of our time to report them (even if some of them can be
suppressed).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Robert Pluim <rpluim@gmail.com>,  emacs-devel@gnu.org
> Date: Thu, 14 Oct 2021 18:42:38 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Theyʼre all in packages, so far.
> >
> > Those should be reported to the corresponding developers.
> 
> Having compilation warnings in packages is very normal (and is because
> the packages target a wide range of Emacs versions).  I don't think it's
> a productive use of our time to report them (even if some of them can be
> suppressed).

I won't insist.

Re: native-comp-async-report-warnings-errors default value

[Robert Pluim]

>>>>> On Thu, 14 Oct 2021 18:57:25 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: emacs-devel@gnu.org
    >> Date: Thu, 14 Oct 2021 16:48:31 +0200
    >> 
    >> >>>>> On Thu, 14 Oct 2021 14:52:32 +0300, Eli Zaretskii <eliz@gnu.org> said:
    >> 
    >> >> As long as we do it just before we release emacs-28, I guess thatʼs
    >> >> OK.
    >> 
    Eli> Please report the warnings, if they are in core files.
    >> 
    >> Theyʼre all in packages, so far.

    Eli> Those should be reported to the corresponding developers.

    >> Although one of those is org, so perhaps I should switch back to the
    >> in-tree version for a while.

    Eli> Is your current version newer than the one on emacs-28?  If so, I
    Eli> think the warnings should be reported to Org developers.

No, itʼs older, which is why Iʼll switch to the in-repo one.

Robert
-- 

Re: native-comp-async-report-warnings-errors default value

[Stefan Kangas]

Robert Pluim <rpluim@gmail.com> writes:

>     Eli> No, not yet: too many problems that trigger those warnings need to be
>     Eli> fixed rather than swept under the carpet of silence.  But you can do
>     Eli> it in your customizations if you don't want to be bothered.
>
> As long as we do it just before we release emacs-28, I guess thatʼs
> OK.

Is it time to make this change on emacs-28 now?  Do we have any real
problems left to fix in Emacs itself?

If it is important to keep, how about a default like

    (= emacs-minor-version 0)

so that users at least don't have to see this in the released version?

Note that this gives spurious warnings for general init file stuff like
setting undefined variables:

    Warning (comp): init-general.el:45:7: Warning: assignment to free
variable ‘display-time-24hr-format’
    Warning (comp): init-general.el:46:7: Warning: assignment to free
variable ‘bookmark-save-flag’
    Warning (comp): init-general.el:48:7: Warning: assignment to free
variable ‘Man-width’

(I have tons of these here.)

Re: native-comp-async-report-warnings-errors default value

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>>     Eli> No, not yet: too many problems that trigger those warnings need to be
>>     Eli> fixed rather than swept under the carpet of silence.  But you can do
>>     Eli> it in your customizations if you don't want to be bothered.
>>
>> As long as we do it just before we release emacs-28, I guess thatʼs
>> OK.
>
> Is it time to make this change on emacs-28 now?  Do we have any real
> problems left to fix in Emacs itself?
>
> If it is important to keep, how about a default like
>
>     (= emacs-minor-version 0)
>
> so that users at least don't have to see this in the released version?

I think it would make sense to disable this in the pretests, too, since
we'll be seeing lots of people trying those out, and they'll be getting
all these warnings (that won't be doing them any good).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: native-comp-async-report-warnings-errors default value

[Andrea Corallo]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Robert Pluim <rpluim@gmail.com> writes:
>>
>>>     Eli> No, not yet: too many problems that trigger those warnings need to be
>>>     Eli> fixed rather than swept under the carpet of silence.  But you can do
>>>     Eli> it in your customizations if you don't want to be bothered.
>>>
>>> As long as we do it just before we release emacs-28, I guess thatʼs
>>> OK.
>>
>> Is it time to make this change on emacs-28 now?  Do we have any real
>> problems left to fix in Emacs itself?
>>
>> If it is important to keep, how about a default like
>>
>>     (= emacs-minor-version 0)
>>
>> so that users at least don't have to see this in the released version?
>
> I think it would make sense to disable this in the pretests, too, since
> we'll be seeing lots of people trying those out, and they'll be getting
> all these warnings (that won't be doing them any good).

+1

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 2 Dec 2021 09:03:13 -0800
> Cc: emacs-devel@gnu.org
> 
> Is it time to make this change on emacs-28 now?  Do we have any real
> problems left to fix in Emacs itself?

The situations where you seem to bump into this have nothing to do
with Emacs sources, do they?

> Note that this gives spurious warnings for general init file stuff like
> setting undefined variables:
> 
>     Warning (comp): init-general.el:45:7: Warning: assignment to free
> variable ‘display-time-24hr-format’
>     Warning (comp): init-general.el:46:7: Warning: assignment to free
> variable ‘bookmark-save-flag’
>     Warning (comp): init-general.el:48:7: Warning: assignment to free
> variable ‘Man-width’

Why are you compiling your init files?

Anyway, if we want to disable warning when natively-compiling init
files, how about doing only that?  I'm running a natively-compiled
Emacs 28 for a couple of weeks now, and I have yet to see a single
warning like those above.

Re: native-comp-async-report-warnings-errors default value

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> The situations where you seem to bump into this have nothing to do
> with Emacs sources, do they?

AFAIR, I haven't seen a warning related to Emacs sources in there in a
long time.  I checked the *Warnings* buffer in my current session, and
none of what I have there is related to Emacs sources.

> Why are you compiling your init files?

In pre-historic times I learned that it speeds up start-up.  These days
it's more trouble than it's worth as I routinely leave Emacs running for
weeks on end.  I've been meaning to disable it, but didn't yet bother.

However, I often see this practice recommended in the community, as some
people seem to care deeply about shaving that extra 0.2 seconds (or
whatever it comes up to) off their startup time.

> Anyway, if we want to disable warning when natively-compiling init
> files, how about doing only that?  I'm running a natively-compiled
> Emacs 28 for a couple of weeks now, and I have yet to see a single
> warning like those above.

We should note that this will lead to (potentially a lot of) warnings
from third-party packages, many of which are rather slow to react to
compiler warnings.  Maybe this will light a fire under them though.

Also, can we tell what is an init file and what is a package?

How do we see this affecting the first pretest?  I am ready to release
the tarball I have now, but if we want to change anything here I can
recreate and reconfirm with the relevant change at the drop of a hat.

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 2 Dec 2021 11:27:45 -0800
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> Also, can we tell what is an init file and what is a package?

Emacs knows when it loads the init file.  We could disable warnings
during that load, perhaps.

> How do we see this affecting the first pretest?  I am ready to release
> the tarball I have now, but if we want to change anything here I can
> recreate and reconfirm with the relevant change at the drop of a hat.

That's exactly why I don't want to make any significant changes at
this time.  We have waited long enough for the pretest, so let's
proceed without further ado.

Re: native-comp-async-report-warnings-errors default value

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1378 bytes --]

Stefan Kangas <stefankangas@gmail.com> writes:


This warning also triggers for 3rd party packages that have complex
build dependencies.
> Robert Pluim <rpluim@gmail.com> writes:
>
>>     Eli> No, not yet: too many problems that trigger those warnings need to be
>>     Eli> fixed rather than swept under the carpet of silence.  But you can do
>>     Eli> it in your customizations if you don't want to be bothered.
>>
>> As long as we do it just before we release emacs-28, I guess that0¶3s
>> OK.
>
> Is it time to make this change on emacs-28 now?  Do we have any real
> problems left to fix in Emacs itself?
>
> If it is important to keep, how about a default like
>
>     (= emacs-minor-version 0)
>
> so that users at least don't have to see this in the released version?
>
> Note that this gives spurious warnings for general init file stuff like
> setting undefined variables:
>
>     Warning (comp): init-general.el:45:7: Warning: assignment to free
> variable ¡®display-time-24hr-format¡¯
>     Warning (comp): init-general.el:46:7: Warning: assignment to free
> variable ¡®bookmark-save-flag¡¯
>     Warning (comp): init-general.el:48:7: Warning: assignment to free
> variable ¡®Man-width¡¯
>
> (I have tons of these here.)
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: native-comp-async-report-warnings-errors default value

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1297 bytes --]

Andrea Corallo <akrl@sdf.org> writes:


They're mostly spurious except when they are not, and in those cases,
the packages generating them will likely misbehave.
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Stefan Kangas <stefankangas@gmail.com> writes:
>>
>>> Robert Pluim <rpluim@gmail.com> writes:
>>>
>>>>     Eli> No, not yet: too many problems that trigger those warnings need to be
>>>>     Eli> fixed rather than swept under the carpet of silence.  But you can do
>>>>     Eli> it in your customizations if you don't want to be bothered.
>>>>
>>>> As long as we do it just before we release emacs-28, I guess that0¶3s
>>>> OK.
>>>
>>> Is it time to make this change on emacs-28 now?  Do we have any real
>>> problems left to fix in Emacs itself?
>>>
>>> If it is important to keep, how about a default like
>>>
>>>     (= emacs-minor-version 0)
>>>
>>> so that users at least don't have to see this in the released version?
>>
>> I think it would make sense to disable this in the pretests, too, since
>> we'll be seeing lots of people trying those out, and they'll be getting
>> all these warnings (that won't be doing them any good).
>
> +1
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Cc: Robert Pluim <rpluim@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org
> Date: Thu, 02 Dec 2021 13:14:52 -0800
> 
> This warning also triggers for 3rd party packages that have complex
> build dependencies.

The variable is there, available for local customizations if some
unusual need arises.  This discussion is about the default value.

Re: native-comp-async-report-warnings-errors default value

[Stefan Kangas]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Thu, 2 Dec 2021 11:27:45 -0800
>> Cc: rpluim@gmail.com, emacs-devel@gnu.org
>>
>> Also, can we tell what is an init file and what is a package?
>
> Emacs knows when it loads the init file.  We could disable warnings
> during that load, perhaps.

That works until you require some package from there, I think.  In any
case, that would need someone to step up to write that code, and it
sounds a whole deal more complicated than just flipping
native-comp-async-report-warnings-errors to nil.

And even then, it won't fix the issue completely.

Please see the attached file with just the warnings I get from starting
Emacs with current master and my init file.  I disabled compiling my
init files, so this is just what I get from third-party packages.  Not
all of them though, as some of them aren't yet loaded -- I will have fun
with a *Warning* buffer popping up in the middle of doing something else
every now and then for the next week or more.

Some of these packages haven't seen updates in years, so I have little
confidence that these warnings will suddenly be fixed in time for Emacs
28.1, even if I did spend a day or two going through and reporting bugs
for all of them.  In some cases, I already have open pull requests that
have seen no action or reply in over a year (!).  And then remains, of
course, the many thousands packages that neither I or anyone else on
this list use.

I am all for showing warnings visibly, but this is an overly intrusive
way to do it, as is evidenced by the many complaints we've seen about it
so far.  In conclusion, I insist that we would do well to flip the
default of native-comp-async-report-warnings-errors to `silent' or nil
for the second Emacs 28 pretest.

[-- Attachment #2: warnings.txt --]
[-- Type: text/plain, Size: 26228 bytes --]

Warning (comp): debian-ispell.el:229:17: Warning: assignment to free variable ‘really-hunspell’ Disable showing Disable logging
Warning (comp): debian-ispell.el:228:28: Warning: reference to free variable ‘really-hunspell’ Disable showing Disable logging
Warning (comp): debian-ispell.el:386:16: Warning: reference to free variable ‘ispell-program-name’ Disable showing Disable logging
Warning (comp): debian-ispell.el:392:16: Warning: reference to free variable ‘ispell-local-dictionary’ Disable showing Disable logging
Warning (comp): debian-ispell.el:393:16: Warning: reference to free variable ‘ispell-dictionary’ Disable showing Disable logging
Warning (comp): debian-ispell.el:403:24: Warning: assignment to free variable ‘ispell-base-dicts-override-alist’ Disable showing Disable logging
Warning (comp): debian-ispell.el:403:20: Warning: reference to free variable ‘ispell-base-dicts-override-alist’ Disable showing Disable logging
Warning (comp): debian-ispell.el:450:10: Warning: reference to free variable ‘ispell-dictionary’ Disable showing Disable logging
Warning (comp): debian-ispell.el:450:10: Warning: reference to free variable ‘ispell-program-name’ Disable showing Disable logging
Warning (comp): debian-ispell.el:469:38: Warning: reference to free variable ‘debian-emacs-flavor’ Disable showing Disable logging
Warning (comp): debian-ispell.el:493:15: Warning: the function ‘ispell-set-spellchecker-params’ is not known to be defined. Disable showing Disable logging
Warning (comp): bind-key.el:134:20: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): dash.el:615:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:628:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:645:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1059:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1219:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1272:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1320:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1335:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1341:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1523:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:2613:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:2632:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:3318:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): s.el:402:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): s.el:407:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ag.el:171:1: Warning: defvar `ag/file-column-pattern-nogroup' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ag.el:179:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ag.el:202:13: Warning: (lambda nil \.\.\.) quoted with ' rather than with #' Disable showing Disable logging
Warning (comp): centered-window.el:75:1: Warning: custom-declare-variable `cwm-incremental-padding' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): centered-window.el:218:69: Warning: reference to free variable ‘centered-window-mode’ Disable showing Disable logging
Warning (comp): centered-window.el:275:7: Warning: reference to free variable ‘centered-window-mode’ Disable showing Disable logging
Warning (comp): discover.el:414:31: Warning: defcustom for ‘global-discover-mode’ fails to specify containing group Disable showing Disable logging
Warning (comp): discover.el:414:31: Warning: defcustom for ‘global-discover-mode’ fails to specify containing group Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:252:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:273:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:352:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:381:23: Warning: reference to free variable ‘mc/cmds-to-run-for-all’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:381:23: Warning: assignment to free variable ‘mc/cmds-to-run-for-all’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:382:21: Warning: reference to free variable ‘mc/cmds-to-run-once’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:382:21: Warning: assignment to free variable ‘mc/cmds-to-run-once’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:468:56: Warning: reference to free variable ‘mc--default-cmds-to-run-once’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:469:56: Warning: reference to free variable ‘mc/cmds-to-run-once’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:471:55: Warning: reference to free variable ‘mc--default-cmds-to-run-for-all’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:472:55: Warning: reference to free variable ‘mc/cmds-to-run-for-all’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:566:1: Warning: defcustom for ‘mc/mode-line’ fails to specify type Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:566:1: Warning: defcustom for ‘mc/mode-line’ fails to specify type Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:577:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): mc-cycle-cursors.el:95:22: Warning: reference to free variable ‘mc/cycle’ Disable showing Disable logging
Warning (comp): mc-mark-more.el:212:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:229:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:246:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:265:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:276:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:326:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:332:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:473:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:493:4: Warning: ‘set-temporary-overlay-map’ is an obsolete function (as of 24.4); use ‘set-transient-map’ instead. Disable showing Disable logging
Warning (comp): mc-mark-more.el:495:1: Warning: defvar `mc/mark-more-like-this-extended-direction' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:642:14: Warning: looking-back called with 1 argument, but requires 2-3 Disable showing Disable logging
Warning (comp): mc-mark-more.el:694:27: Warning: the function ‘sgml-skip-tag-forward’ is not known to be defined. Disable showing Disable logging
Warning (comp): mc-mark-more.el:643:8: Warning: the function ‘sgml-get-context’ is not known to be defined. Disable showing Disable logging
Warning (comp): mc-hide-unmatched-lines-mode.el:59:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): iedit-lib.el:138:1: Warning: defvar `iedit-lib-skip-invisible-count' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): iedit-lib.el:1144:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): iedit.el:173:1: Warning: defvar `iedit-default-occurrence-local' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ioccur.el:378:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ioccur.el:400:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ioccur.el:886:33: Warning: ‘tooltip-use-echo-area’ is an obsolete variable (as of 24.1); disable Tooltip mode instead Disable showing Disable logging
Warning (comp): ioccur.el:1103:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): rectangular-region-mode.el:52:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): rectangular-region-mode.el:115:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): openwith.el:97:14: Warning: reference to free variable ‘openwith-mode’ Disable showing Disable logging
Warning (comp): openwith.el:117:18: Warning: the function ‘recentf-add-file’ is not known to be defined. Disable showing Disable logging
Warning (comp): openwith.el:93:4: Warning: the function ‘w32-shell-execute’ is not known to be defined. Disable showing Disable logging
Warning (comp): undo-tree.el:2352:16: Warning: ‘undo-elt-crosses-region’ is an obsolete function (as of 25.1). Disable showing Disable logging
Warning (comp): undo-tree.el:2561:16: Warning: ‘undo-elt-crosses-region’ is an obsolete function (as of 25.1). Disable showing Disable logging
Warning (comp): undo-tree.el:2755:5: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): undo-tree.el:3140:14: Warning: ‘registerv-make’ is an obsolete function (as of 27.1); Use your own type with methods on register-val-(insert|describe|jump-to) Disable showing Disable logging
Warning (comp): hydra.el:103:1: Warning: defvar `hydra-amaranth-warn-message' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): elfeed-org.el:173:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): elfeed-org.el:186:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): elfeed-org.el:155:10: Warning: the function ‘org-element-put-property’ is not known to be defined. Disable showing Disable logging
Warning (comp): elfeed-org.el:116:34: Warning: the function ‘org-element-property’ is not known to be defined. Disable showing Disable logging
Warning (comp): elfeed-org.el:113:8: Warning: the function ‘org-element-parse-buffer’ is not known to be defined. Disable showing Disable logging
Warning (comp): elfeed-org.el:112:4: Warning: the function ‘org-element-map’ is not known to be defined. Disable showing Disable logging
Warning (comp): counsel.el:3021:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): counsel.el:3075:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): counsel.el:5573:26: Warning: reference to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5576:38: Warning: reference to free variable ‘kmacro-initial-counter-value’ Disable showing Disable logging
Warning (comp): counsel.el:5576:67: Warning: reference to free variable ‘kmacro-counter’ Disable showing Disable logging
Warning (comp): counsel.el:5600:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): counsel.el:5618:8: Warning: reference to free variable ‘kmacro-counter-value-start’ Disable showing Disable logging
Warning (comp): counsel.el:5619:8: Warning: reference to free variable ‘kmacro-counter-format-start’ Disable showing Disable logging
Warning (comp): counsel.el:5620:5: Warning: reference to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5625:30: Warning: Unused lexical variable `kmacro-counter-format-start' Disable showing Disable logging
Warning (comp): counsel.el:5638:23: Warning: reference to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5644:44: Warning: assignment to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5663:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): counsel.el:5681:31: Warning: reference to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5701:58: Warning: reference to free variable ‘kmacro-counter’ Disable showing Disable logging
Warning (comp): counsel.el:5712:31: Warning: reference to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5712:31: Warning: assignment to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5740:16: Warning: Unused lexical variable `kmacro-initial-counter-value' Disable showing Disable logging
Warning (comp): counsel.el:5740:31: Warning: Unused lexical variable `kmacro-counter-format-start' Disable showing Disable logging
Warning (comp): counsel.el:5682:10: Warning: the function ‘kmacro-cycle-ring-previous’ is not known to be defined. Disable showing Disable logging
Warning (comp): counsel.el:5668:6: Warning: the function ‘kmacro-set-format’ is not known to be defined. Disable showing Disable logging
Warning (comp): counsel.el:5661:6: Warning: the function ‘kmacro-set-counter’ is not known to be defined. Disable showing Disable logging
Warning (comp): counsel.el:5449:28: Warning: the function ‘list-colors-duplicates’ is not known to be defined. Disable showing Disable logging
Warning (comp): notmuch-draft.el:38:1: Warning: custom-declare-variable `notmuch-draft-tags' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-message.el:53:1: Warning: defconst `notmuch-message-queued-tag-changes' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-show.el:2318:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-show.el:2340:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-show.el:2351:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-show.el:2367:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-hello.el:122:1: Warning: custom-declare-variable `notmuch-saved-searches' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-hello.el:691:22: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-hello.el:869:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-tree.el:971:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-tree.el:768:8: Warning: the function ‘notmuch-tree-from-search-thread’ is not known to be defined. Disable showing Disable logging
Warning (comp): notmuch-tree.el:767:10: Warning: the function ‘notmuch-search-next-thread’ is not known to be defined. Disable showing Disable logging
Warning (comp): notmuch-tree.el:766:12: Warning: the function ‘notmuch-search-previous-thread’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:109:43: Warning: reference to free variable ‘notmuch-search-query-string’ Disable showing Disable logging
Warning (comp): ol-notmuch.el:150:4: Warning: the function ‘notmuch-tree’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:135:42: Warning: the function ‘notmuch-tree-get-query’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:124:4: Warning: the function ‘notmuch-search’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:98:4: Warning: the function ‘notmuch-show’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:80:29: Warning: the function ‘notmuch-show-get-date’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:79:19: Warning: the function ‘notmuch-show-get-from’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:78:17: Warning: the function ‘notmuch-show-get-to’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:77:22: Warning: the function ‘notmuch-show-get-subject’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:76:25: Warning: the function ‘notmuch-show-get-message-id’ is not known to be defined. Disable showing Disable logging
Warning (comp): org-bullets.el:111:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): org-download.el:558:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): org-download.el:526:22: Warning: the function ‘url-handler-file-remote-p’ is not known to be defined. Disable showing Disable logging
Warning (comp): company.el:785:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): company.el:1977:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): org-journal.el:430:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): org-journal.el:505:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): org-journal.el:571:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): org-journal.el:722:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): org-journal.el:1048:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): org-journal.el:1517:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:1224:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2058:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2066:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2075:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2083:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2089:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2100:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2198:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2225:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2253:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2449:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2571:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2586:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2639:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2691:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2735:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:3397:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:3412:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:3518:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:3547:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:3558:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:4466:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:4965:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:1458:1: Warning: custom-declare-variable `sp-highlight-wrap-tag-overlay' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:2724:42: Warning: value returned from (< (sp--get-overlay-length nil) (sp--get-overlay-length nil)) is unused Disable showing Disable logging
Warning (comp): smartparens.el:2724:42: Warning: value returned from (< (sp--get-overlay-length nil) (sp--get-overlay-length nil)) is unused Disable showing Disable logging
Warning (comp): smartparens.el:2724:42: Warning: value returned from (< (sp--get-overlay-length nil) (sp--get-overlay-length nil)) is unused Disable showing Disable logging
Warning (comp): smartparens.el:2905:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:2911:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:5520:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:7186:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:8215:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:8714:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:9397:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ws-butler.el:153:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): aggressive-indent.el:503:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): aggressive-indent.el:504:16: Warning: reference to free variable ‘global-aggressive-indent-mode’ Disable showing Disable logging
Warning (comp): stream.el:316:15: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): stream-x.el:103:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): el-search.el:996:15: Warning: elisp--highlight-function-argument called with 4 arguments, but accepts only 3 Disable showing Disable logging
Warning (comp): el-search.el:2569:26: Warning: global/dynamic var ‘type’ lacks a prefix Disable showing Disable logging
Warning (comp): nameless.el:286:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): macrostep.el:291:1: Warning: defvar `macrostep-outer-environment' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): macrostep.el:363:1: Warning: custom-declare-variable `macrostep-expand-compiler-macros' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): macrostep.el:503:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): loop.el:105:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): loop.el:117:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): suggest.el:434:10: Warning: ‘format-proper-list-p’ is an obsolete function (as of 27.1); use ‘proper-list-p’ instead. Disable showing Disable logging
Warning (comp): winum.el:241:3: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): yasnippet.el:477:1: Warning: defvar `yas-after-exit-snippet-hook' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): yasnippet.el:559:1: Warning: custom-declare-variable `yas-keymap-disable-hook' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): yasnippet.el:1812:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): yasnippet.el:2984:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): yasnippet.el:4737:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): .yas-setup.el:31:8: Warning: docstring wider than 80 characters Disable showing Disable logging

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 6 Dec 2021 21:11:21 +0100
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> > Emacs knows when it loads the init file.  We could disable warnings
> > during that load, perhaps.
> 
> That works until you require some package from there, I think.  In any
> case, that would need someone to step up to write that code, and it
> sounds a whole deal more complicated than just flipping
> native-comp-async-report-warnings-errors to nil.

Then flip it.  For yourself.  Why decide for all the others?

I'd rather sustain a barrage of annoyed people who think these
warnings are gratuitous than explain to someone why Emacs decided to
shut up these warnings by default and thus prevented him/her from
seeing some warning which, if seen in time, could avoid a crash or
some other catastrophic result.

Native compilation is still in its diapers.  We learn about new
aspects and potential issues with it almost every day.  Sweeping
warnings under the carpet in this situation makes very little sense to
me.  It's our minimal safety net.

But if "by popular demand" and other pressure, you will decide to
disable the warnings nonetheless, I won't mount the barricades.  My
opinion about this is unchanged, but feel free to disregard it.

Re: native-comp-async-report-warnings-errors default value

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'd rather sustain a barrage of annoyed people who think these
> warnings are gratuitous than explain to someone why Emacs decided to
> shut up these warnings by default and thus prevented him/her from
> seeing some warning which, if seen in time, could avoid a crash or
> some other catastrophic result.

In my opinion, it's not something we should be showing to users.  It's
highly irregular that we do -- we didn't present users saying "emacs"
with all the compilation warnings from building Emacs in Emacs 27.2, but
that's (in effect) what we're doing now.

Compilation warnings are for developers, not users, so builds that are
geared towards users (as pretests are) should have this switched off.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: native-comp-async-report-warnings-errors default value

[Andrea Corallo]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I'd rather sustain a barrage of annoyed people who think these
>> warnings are gratuitous than explain to someone why Emacs decided to
>> shut up these warnings by default and thus prevented him/her from
>> seeing some warning which, if seen in time, could avoid a crash or
>> some other catastrophic result.
>
> In my opinion, it's not something we should be showing to users.  It's
> highly irregular that we do -- we didn't present users saying "emacs"
> with all the compilation warnings from building Emacs in Emacs 27.2, but
> that's (in effect) what we're doing now.
>
> Compilation warnings are for developers, not users, so builds that are
> geared towards users (as pretests are) should have this switched off.

What is the problem with changing it after pretest is done?

In the Emacs world by definition there's no clear distinction between
users and developers, postponing the switch we maximize the probability
that some user/developer fix some broken code no?

  Andrea

Re: native-comp-async-report-warnings-errors default value

[Robert Pluim]

>>>>> On Tue, 07 Dec 2021 09:37:30 +0000, Andrea Corallo <akrl@sdf.org> said:

    Andrea> What is the problem with changing it after pretest is done?

    Andrea> In the Emacs world by definition there's no clear distinction between
    Andrea> users and developers, postponing the switch we maximize the probability
    Andrea> that some user/developer fix some broken code no?

Are there clear instructions somewhere mapping from the warnings to
the changes required in the 'broken code'? (I wouldnʼt call it 'broken'
if it works in current Emacs)

Robert
-- 

Re: native-comp-async-report-warnings-errors default value

[Andrea Corallo]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Tue, 07 Dec 2021 09:37:30 +0000, Andrea Corallo <akrl@sdf.org> said:
>
>     Andrea> What is the problem with changing it after pretest is done?
>
>     Andrea> In the Emacs world by definition there's no clear distinction between
>     Andrea> users and developers, postponing the switch we maximize the probability
>     Andrea> that some user/developer fix some broken code no?
>
> Are there clear instructions somewhere mapping from the warnings to
> the changes required in the 'broken code'? (I wouldnʼt call it 'broken'
> if it works in current Emacs)

The docstring of `native-comp-async-report-warnings-errors' itself
mention the tipical reason of this and its classical fix.  It might be
mentioned elsewhere tho, not sure.

  Andrea

Re: native-comp-async-report-warnings-errors default value

[Robert Pluim]

>>>>> On Tue, 07 Dec 2021 09:54:12 +0000, Andrea Corallo <akrl@sdf.org> said:

    Andrea> Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Tue, 07 Dec 2021 09:37:30 +0000, Andrea Corallo <akrl@sdf.org> said:
    >> 
    Andrea> What is the problem with changing it after pretest is done?
    >> 
    Andrea> In the Emacs world by definition there's no clear distinction between
    Andrea> users and developers, postponing the switch we maximize the probability
    Andrea> that some user/developer fix some broken code no?
    >> 
    >> Are there clear instructions somewhere mapping from the warnings to
    >> the changes required in the 'broken code'? (I wouldnʼt call it 'broken'
    >> if it works in current Emacs)

    Andrea> The docstring of `native-comp-async-report-warnings-errors' itself
    Andrea> mention the tipical reason of this and its classical fix.  It might be
    Andrea> mentioned elsewhere tho, not sure.

Itʼs not in the elisp manual. I think the docstring of
`native-comp-async-report-warnings-errors' is also not discoverable
from the *Warnings* buffer, from what I remember.

Robert
-- 

Re: native-comp-async-report-warnings-errors default value

[Stefan Monnier]

> What is the problem with changing it after pretest is done?

That's too late: changing something *after* the last pretest means
releasing code that has never been tested.  A pretest is basically
a release candidate.


        Stefan

Re: native-comp-async-report-warnings-errors default value

[Andrea Corallo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> What is the problem with changing it after pretest is done?
>
> That's too late: changing something *after* the last pretest means
> releasing code that has never been tested.  A pretest is basically
> a release candidate.

Okay, my understanding was this was our intention, I guess I've got it
wrong.

  Andrea

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  rpluim@gmail.com,
>   emacs-devel@gnu.org
> Date: Tue, 07 Dec 2021 08:51:28 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'd rather sustain a barrage of annoyed people who think these
> > warnings are gratuitous than explain to someone why Emacs decided to
> > shut up these warnings by default and thus prevented him/her from
> > seeing some warning which, if seen in time, could avoid a crash or
> > some other catastrophic result.
> 
> In my opinion, it's not something we should be showing to users.  It's
> highly irregular that we do -- we didn't present users saying "emacs"
> with all the compilation warnings from building Emacs in Emacs 27.2, but
> that's (in effect) what we're doing now.
> 
> Compilation warnings are for developers, not users, so builds that are
> geared towards users (as pretests are) should have this switched off.

If the user visits a Lisp file and clicks the Emacs Lisp->Byte Compile
item on the menu bar, we do pop up the compilation log buffer with the
warnings and errors, right?

And if the user installs or upgrades a package from ELPA, and the
package is byte-compiled, the messages from that are shown, right?

So it sounds like we already show these messages to users, and this is
just another such situation.  Once we decided to have JIT native
compilation (and IMO it wouldn't make sense to decide differently), we
should also agree to this side effect of compiling code in the
background.

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  Eli Zaretskii <eliz@gnu.org>,
>   Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org
> Date: Tue, 07 Dec 2021 13:38:01 +0100
> 
> >>>>> On Tue, 07 Dec 2021 09:54:12 +0000, Andrea Corallo <akrl@sdf.org> said:
> 
>     Andrea> Robert Pluim <rpluim@gmail.com> writes:
>     >>>>>>> On Tue, 07 Dec 2021 09:37:30 +0000, Andrea Corallo <akrl@sdf.org> said:
>     >> 
>     Andrea> What is the problem with changing it after pretest is done?
>     >> 
>     Andrea> In the Emacs world by definition there's no clear distinction between
>     Andrea> users and developers, postponing the switch we maximize the probability
>     Andrea> that some user/developer fix some broken code no?
>     >> 
>     >> Are there clear instructions somewhere mapping from the warnings to
>     >> the changes required in the 'broken code'? (I wouldnʼt call it 'broken'
>     >> if it works in current Emacs)
> 
>     Andrea> The docstring of `native-comp-async-report-warnings-errors' itself
>     Andrea> mention the tipical reason of this and its classical fix.  It might be
>     Andrea> mentioned elsewhere tho, not sure.
> 
> Itʼs not in the elisp manual. I think the docstring of
> `native-comp-async-report-warnings-errors' is also not discoverable
> from the *Warnings* buffer, from what I remember.

We can always improve the documentation in this area.  Feel free to
propose a patch, or explain what needs to be improved there, so that
someone else could do it.

TIA

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>,
>         emacs-devel@gnu.org, rpluim@gmail.com,
>         Stefan Kangas
>  <stefan@marxist.se>
> Date: Tue, 07 Dec 2021 14:05:55 +0000
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >> What is the problem with changing it after pretest is done?
> >
> > That's too late: changing something *after* the last pretest means
> > releasing code that has never been tested.  A pretest is basically
> > a release candidate.
> 
> Okay, my understanding was this was our intention

Almost: we talked about disabling it close to the release, but still
during the pretest.  That is still an option: we just had the first
pretest, and there will be definitely at least one more.

Re: native-comp-async-report-warnings-errors default value

[Robert Pluim]

>>>>> On Tue, 07 Dec 2021 16:28:22 +0200, Eli Zaretskii <eliz@gnu.org> said:
    >> Itʼs not in the elisp manual. I think the docstring of
    >> `native-comp-async-report-warnings-errors' is also not discoverable
    >> from the *Warnings* buffer, from what I remember.

    Eli> We can always improve the documentation in this area.  Feel free to
    Eli> propose a patch, or explain what needs to be improved there, so that
    Eli> someone else could do it.

Let the wordsmithing begin!

diff --git a/doc/lispref/compile.texi b/doc/lispref/compile.texi
index 523758c10f..a3557e6855 100644
--- a/doc/lispref/compile.texi
+++ b/doc/lispref/compile.texi
@@ -924,7 +924,11 @@ Native-Compilation Functions
 use while the compilation runs in the background.  This is the method
 used by Emacs to natively-compile any Lisp file or byte-compiled Lisp
 file that is loaded into Emacs, when no natively-compiled file for it
-is available.
+is available.  Note that because of this use of a subprocess, native
+compilation may produce warning and errors which byte-compilation does
+not, and lisp code may thus need to be modified to work correctly. See
+@code{native-comp-async-report-warnings-errors} in @xref{Native-Compilation
+Variables} for more details.
 
 @defun native-compile-async files &optional recursively load selector
 This function compiles the named @var{files} asynchronously.  The
@@ -1038,6 +1042,12 @@ Native-Compilation Variables
 @code{t} means display the resulting buffer.  To log warnings without
 popping up the @file{*Warnings*} buffer, set this variable to
 @code{silent}.
+
+  A common cause for asynchronous native-compilation to produce
+warnings is compiling a file that is missing some @code{require} of a
+necessary feature.  The feature may be loaded into the main emacs, but
+because native compilation always starts from a subprocess with a
+pristine environment, that may not be true for the subprocess.
 @end defopt
 
 @defopt native-comp-async-query-on-exit

diff --git a/doc/lispref/compile.texi b/doc/lispref/compile.texi
index 523758c10f..850cdff465 100644
--- a/doc/lispref/compile.texi
+++ b/doc/lispref/compile.texi
@@ -924,7 +924,10 @@ Native-Compilation Functions
 use while the compilation runs in the background.  This is the method
 used by Emacs to natively-compile any Lisp file or byte-compiled Lisp
 file that is loaded into Emacs, when no natively-compiled file for it
-is available.
+is available.  Note that because of this use of a subprocess, native
+compilation may produce warning and errors which byte-compilation does
+not, and lisp code may thus need to be modified to work correctly. See
+@code{native-comp-async-report-warnings-errors} for more details.
 
 @defun native-compile-async files &optional recursively load selector
 This function compiles the named @var{files} asynchronously.  The

Regarding discoverability, the
*Warnings* buffer has entries like this:

    Warning (comp): tex-site.el:168:31: Warning: the function
    ‘BibTeX-auto-store’ is not known to be defined. Disable showing
    Disable logging

I guess we could add a link to
`native-comp-async-report-warnings-errors' when the warning type == (comp)

Robert
-- 

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: akrl@sdf.org,  larsi@gnus.org,  stefankangas@gmail.com,
>   emacs-devel@gnu.org
> Date: Tue, 07 Dec 2021 17:54:49 +0100
> 
> Let the wordsmithing begin!

Thanks, this is fine, with two gotchas:

> +is available.  Note that because of this use of a subprocess, native
> +compilation may produce warning and errors which byte-compilation does
> +not, and lisp code may thus need to be modified to work correctly. See
                                                                    ^^
Two spaces there, please.

> +@code{native-comp-async-report-warnings-errors} in @xref{Native-Compilation

@xref is inappropriate in the middle of a sentence, since it produces
a capitalized "See".  You want @pxref instead.

> Regarding discoverability, the
> *Warnings* buffer has entries like this:
> 
>     Warning (comp): tex-site.el:168:31: Warning: the function
>     ‘BibTeX-auto-store’ is not known to be defined. Disable showing
>     Disable logging
> 
> I guess we could add a link to
> `native-comp-async-report-warnings-errors' when the warning type == (comp)

We could, yes.  Assuming the code to add that is simple enough to
install on the release branch.

Thanks.

Re: native-comp-async-report-warnings-errors default value

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If the user visits a Lisp file and clicks the Emacs Lisp->Byte Compile
> item on the menu bar, we do pop up the compilation log buffer with the
> warnings and errors, right?

That is an explicit action, so I don't think it applies here.

> And if the user installs or upgrades a package from ELPA, and the
> package is byte-compiled, the messages from that are shown, right?

That is quite similar to the native-comp situation, yes.

> So it sounds like we already show these messages to users, and this is
> just another such situation.  Once we decided to have JIT native
> compilation (and IMO it wouldn't make sense to decide differently), we
> should also agree to this side effect of compiling code in the
> background.

The problem is that the JIT can happen at any point, without the user
having done anything explicitly.  Anything that's autoloaded and fetched
when looking at *Help*, for instance, might trigger JIT and pop up
warnings to the user -- warnings that are 100% irrelevant for that user.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: native-comp-async-report-warnings-errors default value

[Robert Pluim]

>>>>> On Tue, 07 Dec 2021 19:16:16 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: akrl@sdf.org,  larsi@gnus.org,  stefankangas@gmail.com,
    >> emacs-devel@gnu.org
    >> Date: Tue, 07 Dec 2021 17:54:49 +0100
    >> 
    >> Let the wordsmithing begin!

    Eli> Thanks, this is fine, with two gotchas:

    >> +is available.  Note that because of this use of a subprocess, native
    >> +compilation may produce warning and errors which byte-compilation does
    >> +not, and lisp code may thus need to be modified to work correctly. See
    Eli>                                                                     ^^
    Eli> Two spaces there, please.

    >> +@code{native-comp-async-report-warnings-errors} in @xref{Native-Compilation

    Eli> @xref is inappropriate in the middle of a sentence, since it produces
    Eli> a capitalized "See".  You want @pxref instead.

Fixed and pushed to emacs-28.

    >> I guess we could add a link to
    >> `native-comp-async-report-warnings-errors' when the warning type == (comp)

    Eli> We could, yes.  Assuming the code to add that is simple enough to
    Eli> install on the release branch.

Something like this, although this puts the button on all warnings,
not just the ones about missing definitions. And now Iʼm tempted to
*remove* the 'Disable' buttons for 'comp' warnings, since clicking
those will suppress all native compilation warnings.

diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
index 36b275e2d3..8aa6d18d61 100644
--- a/lisp/emacs-lisp/warnings.el
+++ b/lisp/emacs-lisp/warnings.el
@@ -298,6 +298,12 @@ display-warning
               ;; Don't output the buttons when doing batch compilation
               ;; and similar.
               (unless (or noninteractive (eq type 'bytecomp))
+                (when (eq type 'comp)
+                  (insert " ")
+                  (insert-button "More Info"
+                                 'help-echo "mouse-2, RET: Show native-compile documentation"
+                                 'action (lambda (_)
+                                           (describe-variable 'native-comp-async-report-warnings-errors))))
                 (insert " ")
                 (insert-button "Disable showing"
                                'type 'warning-suppress-warning

(I really must either update some packages or hassle their
authors. Iʼm getting like 200 warnings)

Robert
-- 

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: akrl@sdf.org,  larsi@gnus.org,  stefankangas@gmail.com,
>   emacs-devel@gnu.org
> Date: Wed, 08 Dec 2021 10:19:59 +0100
> 
>     >> I guess we could add a link to
>     >> `native-comp-async-report-warnings-errors' when the warning type == (comp)
> 
>     Eli> We could, yes.  Assuming the code to add that is simple enough to
>     Eli> install on the release branch.
> 
> Something like this, although this puts the button on all warnings,
> not just the ones about missing definitions.

Opinions about such a change, anyone?

> And now Iʼm tempted to
> *remove* the 'Disable' buttons for 'comp' warnings, since clicking
> those will suppress all native compilation warnings.

It was added there to do precisely that, so I think removing it would
be a step back.

Thanks.

Re: native-comp-async-report-warnings-errors default value

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: akrl@sdf.org,  larsi@gnus.org,  stefankangas@gmail.com,
>>   emacs-devel@gnu.org
>> Date: Wed, 08 Dec 2021 10:19:59 +0100
>> 
>>     >> I guess we could add a link to
>>     >> `native-comp-async-report-warnings-errors' when the warning type == (comp)
>> 
>>     Eli> We could, yes.  Assuming the code to add that is simple enough to
>>     Eli> install on the release branch.
>> 
>> Something like this, although this puts the button on all warnings,
>> not just the ones about missing definitions.
>
> Opinions about such a change, anyone?

Sounds to me it might be useful to users.

  Andrea

Re: native-comp-async-report-warnings-errors default value

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Then flip it.  For yourself.  Why decide for all the others?

I have been reluctant to do that, as that would stop me from testing how
it works by default.

> But if "by popular demand" and other pressure, you will decide to
> disable the warnings nonetheless, I won't mount the barricades.  My
> opinion about this is unchanged, but feel free to disregard it.

I just recompiled, and I'm sitting again with mostly unusable Emacs for
the last 5-10 minutes or so.  Warnings popping up in the middle of
searches and trying to get things done.

For example, while writing this email, I was helpfully informed (among
other things) that:

Warning (comp): yasnippet.el:477:1: Warning: defvar
`yas-after-exit-snippet-hook' docstring wider than 80 characters
Disable showing Disable logging

I find the current situation untenable, especially if we expect some
high profile GNU/Linux distributions to be shipping
--with-native-compilation by default.

Unless there is a specific request not to do that from the maintainers,
I intend to flip the default to `silent' on emacs-28 in the next couple
of days.  If there is such a request, I will not insist further.

Thanks in advance.

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 17 Dec 2021 10:14:43 -0800
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But if "by popular demand" and other pressure, you will decide to
> > disable the warnings nonetheless, I won't mount the barricades.  My
> > opinion about this is unchanged, but feel free to disregard it.
> 
> Unless there is a specific request not to do that from the maintainers,
> I intend to flip the default to `silent' on emacs-28 in the next couple
> of days.  If there is such a request, I will not insist further.

When I said "by popular demand", I meant that.  Just your own voice is
not enough, IMO.

Re: native-comp-async-report-warnings-errors default value

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Unless there is a specific request not to do that from the maintainers,
>> I intend to flip the default to `silent' on emacs-28 in the next couple
>> of days.  If there is such a request, I will not insist further.
>
> When I said "by popular demand", I meant that.  Just your own voice is
> not enough, IMO.

My vote is for 'silent too.

As explained on previous messages, I already have nil assigned to that
variable, so I don't care about the outcome of this decission as a user.

I do care as the maintainer of the MSYS2/Mingw-w64 Emacs package,
though.

Re: native-comp-async-report-warnings-errors default value

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> When I said "by popular demand", I meant that.  Just your own voice is
> not enough, IMO.

It seems like we are interpreting the popular opinion quite differently.

Re: native-comp-async-report-warnings-errors default value

[Stefan Kangas]

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> When I said "by popular demand", I meant that.  Just your own voice is
>> not enough, IMO.

I have now reviewed this thread, and changing the default from nil to
silent has the support from Robert Pluim, Stefan Kangas, Lars
Ingebrigtsen, Andrea Corallo and Óscar Fuentes (5).

For keeping the current default I count Eli Zaretskii (1).

Neutral in this thread are T.V. Raman and Stefan Monnier (2).

IOW, there is a clear majority in favor of the proposed change.  However
you choose to interpret this data, saying that this is "just my voice"
is clearly incorrect.

Re: native-comp-async-report-warnings-errors default value

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 17 Dec 2021 12:07:07 -0800
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> When I said "by popular demand", I meant that.  Just your own voice is
> >> not enough, IMO.
> 
> I have now reviewed this thread, and changing the default from nil to
> silent has the support from Robert Pluim, Stefan Kangas, Lars
> Ingebrigtsen, Andrea Corallo and Óscar Fuentes (5).
> 
> For keeping the current default I count Eli Zaretskii (1).
> 
> Neutral in this thread are T.V. Raman and Stefan Monnier (2).
> 
> IOW, there is a clear majority in favor of the proposed change.  However
> you choose to interpret this data, saying that this is "just my voice"
> is clearly incorrect.

Sigh.  Here we go again:

  . if this annoys you so much, then why not change the value in your
    own configuration? why do you insist to change the default?
  . and if we eventually do change the default, why so early in the
    pretest? why not closer to the release?
  . and since when 5 vs 1 out of 8 means "by popular demand"?

Re: native-comp-async-report-warnings-errors default value

[Dmitry Gutov]

On 17.12.2021 23:38, Eli Zaretskii wrote:
>    . if this annoys you so much, then why not change the value in your
>      own configuration? why do you insist to change the default?

FWIW, I've tried native-comp myself once, saw the myriad of warnings and 
returned to a non-native-compiled build in part because of that.

Just one voice, but there must be others who did that too.

>    . and if we eventually do change the default, why so early in the
>      pretest? why not closer to the release?

Closer SGTM. You could make a poll sometime before that.

Re: native-comp-async-report-warnings-errors default value

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>   . if this annoys you so much, then why not change the value in your
>     own configuration? why do you insist to change the default?

I have tried to explain in this thread how the current behavior is
surprising and bad.  Others have done so also.  What I have in my own
configuration is not relevant in that regard, I think.

>   . and if we eventually do change the default, why so early in the
>     pretest? why not closer to the release?

I don't have an opinion about the timing, but I do think it should
happen before Emacs 28.1.

>   . and since when 5 vs 1 out of 8 means "by popular demand"?

My claim was that 5 out of 8 is not "just one voice".

As I already said, I won't insist further so I will be bowing out of
this thread now.  Thanks.

Re: native-comp-async-report-warnings-errors default value

[Colin Baxter 😺]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

    > On 17.12.2021 23:38, Eli Zaretskii wrote:
    >> . if this annoys you so much, then why not change the value in
    >> your own configuration? why do you insist to change the default?

    > FWIW, I've tried native-comp myself once, saw the myriad of
    > warnings and returned to a non-native-compiled build in part
    > because of that.

    > Just one voice, but there must be others who did that too.

I did exactly that a while ago - but then I'm just a nobody. :-)

Re: native-comp-async-report-warnings-errors default value

[Ken Brown]

On 12/17/2021 3:53 PM, Dmitry Gutov wrote:
> On 17.12.2021 23:38, Eli Zaretskii wrote:
>>    . if this annoys you so much, then why not change the value in your
>>      own configuration? why do you insist to change the default?
> 
> FWIW, I've tried native-comp myself once, saw the myriad of warnings and 
> returned to a non-native-compiled build in part because of that.
> 
> Just one voice, but there must be others who did that too.

One more voice: I'm in favor of the current default for 
native-comp-async-report-warnings-errors.

Native compilation is disabled by default.  People who build emacs for their own 
use and choose to try native compilation can see the consequences and make their 
own decision on how to deal with them.  Users who don't like the warnings can 
turn them off.  Users who would rather help fix the problems turned up the 
warnings can leave them on.  Users who just find the whole issue annoying can 
stop building with native compilation.  But if we turned off the warnings by 
default, many users wouldn't even know the options.

Similar remarks apply to people who build emacs as maintainers for a distro.  If 
they choose to build with native compilation and impose that decision on their 
users, they can also choose for their users the default value of 
native-comp-async-report-warnings-errors.

If native compilation were enabled by default, it would be a different story.

Ken

Re: native-comp-async-report-warnings-errors default value

[Rudolf Adamkovič]

Dmitry Gutov <dgutov@yandex.ru> writes:

> FWIW, I've tried native-comp myself once, saw the myriad of warnings and 
> returned to a non-native-compiled build in part because of that.

Same here and +1 vote.  I eventually found the variable, but who has the
time to fiddle with this?  Also, +1 for silencing the warnings when
installing or upgrading packages.

-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't. That's logic.'"
-- Lewis Carroll, Through the Looking Glass

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: native-comp-async-report-warnings-errors default value

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> For keeping the current default I count Eli Zaretskii (1).

FWIW, I support the current default as well.

Re: native-comp-async-report-warnings-errors default value

[Dmitry Gutov]

On 18.12.2021 01:01, Ken Brown wrote:

> Native compilation is disabled by default.  People who build emacs for 
> their own use and choose to try native compilation can see the 
> consequences and make their own decision on how to deal with them.

I agree that as long as we don't intend for it to be on by default, the 
warnings are fine to show.

> Similar remarks apply to people who build emacs as maintainers for a 
> distro.  If they choose to build with native compilation and impose that 
> decision on their users, they can also choose for their users the 
> default value of native-comp-async-report-warnings-errors.

This, however, seems like a bad idea.

The distros don't control, nor are responsible for, the whole 
third-party package ecosystem.

Re: native-comp-async-report-warnings-errors default value

[Ken Brown]

On 12/17/2021 7:48 PM, Dmitry Gutov wrote:
> On 18.12.2021 01:01, Ken Brown wrote:
> 
>> Native compilation is disabled by default.  People who build emacs for their 
>> own use and choose to try native compilation can see the consequences and make 
>> their own decision on how to deal with them.
> 
> I agree that as long as we don't intend for it to be on by default, the warnings 
> are fine to show.
> 
>> Similar remarks apply to people who build emacs as maintainers for a distro.  
>> If they choose to build with native compilation and impose that decision on 
>> their users, they can also choose for their users the default value of 
>> native-comp-async-report-warnings-errors.
> 
> This, however, seems like a bad idea.
> 
> The distros don't control, nor are responsible for, the whole third-party 
> package ecosystem.

Right, which is why distros might well choose to disable warnings.  My point is 
that it's their decision, given that they've already decided to build with 
native compilation, not something that Emacs has to worry about.

Ken

Re: native-comp-async-report-warnings-errors default value

[Óscar Fuentes]

Ken Brown <kbrown@cornell.edu> writes:

> On 12/17/2021 7:48 PM, Dmitry Gutov wrote:
>> On 18.12.2021 01:01, Ken Brown wrote:
>> 
>>> Native compilation is disabled by default.  People who build emacs
>>> for their own use and choose to try native compilation can see the
>>> consequences and make their own decision on how to deal with them.
>> I agree that as long as we don't intend for it to be on by default,
>> the warnings are fine to show.
>> 
>>> Similar remarks apply to people who build emacs as maintainers for
>>> a distro.  If they choose to build with native compilation and
>>> impose that decision on their users, they can also choose for their
>>> users the default value of
>>> native-comp-async-report-warnings-errors.
>> This, however, seems like a bad idea.
>> The distros don't control, nor are responsible for, the whole
>> third-party package ecosystem.
>
> Right, which is why distros might well choose to disable warnings.  My
> point is that it's their decision, given that they've already decided
> to build with native compilation, not something that Emacs has to
> worry about.

IIUC you are saying "that's what they deserve for using native-comp".

Well, building with native-comp enabled is a build configuration
supported by Emacs, changing the default value of
native-comp-async-report-warnings-errors requires patching Emacs or
providing a "vendor" configuration file.

Those are changes at a very different level.

Re: native-comp-async-report-warnings-errors default value

[Ken Brown]

On 12/18/2021 11:58 AM, Óscar Fuentes wrote:
> Ken Brown <kbrown@cornell.edu> writes:
>> Right, which is why distros might well choose to disable warnings.  My
>> point is that it's their decision, given that they've already decided
>> to build with native compilation, not something that Emacs has to
>> worry about.
> 
> IIUC you are saying "that's what they deserve for using native-comp".

No, that's not what I meant, and I'm sorry if I gave that impression.  I like 
native-comp, I use it myself, and at some point I expect to release a version of 
emacs for the Cygwin distribution with native-comp enabled.  What I tried to say 
is that if maintainers choose to enable a build configuration that is not 
enabled by default, they should be aware of the consequences and should deal 
with those consequences as they see fit.

> Well, building with native-comp enabled is a build configuration
> supported by Emacs, changing the default value of
> native-comp-async-report-warnings-errors requires patching Emacs or
> providing a "vendor" configuration file
> Those are changes at a very different level.

Agreed.  And I don't see a problem with making changes at that level.

Ken

Re: native-comp-async-report-warnings-errors default value

[Andrea Corallo]

Stefan Kangas <stefankangas@gmail.com> writes:

>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> When I said "by popular demand", I meant that.  Just your own voice is
>>> not enough, IMO.
>
> I have now reviewed this thread, and changing the default from nil to
> silent has the support from Robert Pluim, Stefan Kangas, Lars
> Ingebrigtsen, Andrea Corallo and Óscar Fuentes (5).
>
> For keeping the current default I count Eli Zaretskii (1).
>
> Neutral in this thread are T.V. Raman and Stefan Monnier (2).

FWIW please count me on the neutral side, I've no formed opinion on this
ATM even if the more time is passing the more I tend to think that the
current default might be safer and/or beneficial on the long run.

Thanks

  Andrea

Re: native-comp-async-report-warnings-errors default value

[Dmitry Gutov]

Hi Andrea,

On 20.12.2021 11:29, Andrea Corallo wrote:
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>> When I said "by popular demand", I meant that.  Just your own voice is
>>>> not enough, IMO.
>>
>> I have now reviewed this thread, and changing the default from nil to
>> silent has the support from Robert Pluim, Stefan Kangas, Lars
>> Ingebrigtsen, Andrea Corallo and Óscar Fuentes (5).
>>
>> For keeping the current default I count Eli Zaretskii (1).
>>
>> Neutral in this thread are T.V. Raman and Stefan Monnier (2).
> 
> FWIW please count me on the neutral side, I've no formed opinion on this
> ATM even if the more time is passing the more I tend to think that the
> current default might be safer and/or beneficial on the long run.

This might be a distracting aside, but could you comment on the idea 
that I think Stefan mentioned previously: that the native compiler could 
use not the original source files, but the byte-compiled *.elc files as 
the "source". By the time those are compiled, all the dependencies are 
resolved one way or another, right? So the user won't need to suffer the 
same kind of warnings again.

Do they contain the necessary information to do native-compile, and its 
various optimizations? If yes, are there any other difficulties 
associated with such an approach?

Re: native-comp-async-report-warnings-errors default value

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1729 bytes --]

Dmitry Gutov <dgutov@yandex.ru> writes:


Thanks for bubbling this back up -- I think this is the real issue ---
and I too hope Andrea will address this last mile of native-comp ---
> Hi Andrea,
>
> On 20.12.2021 11:29, Andrea Corallo wrote:
>> Stefan Kangas <stefankangas@gmail.com> writes:
>> 
>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>
>>>>> When I said "by popular demand", I meant that.  Just your own voice is
>>>>> not enough, IMO.
>>>
>>> I have now reviewed this thread, and changing the default from nil to
>>> silent has the support from Robert Pluim, Stefan Kangas, Lars
>>> Ingebrigtsen, Andrea Corallo and 0ˆ7scar Fuentes (5).
>>>
>>> For keeping the current default I count Eli Zaretskii (1).
>>>
>>> Neutral in this thread are T.V. Raman and Stefan Monnier (2).
>> FWIW please count me on the neutral side, I've no formed opinion on
>> this
>> ATM even if the more time is passing the more I tend to think that the
>> current default might be safer and/or beneficial on the long run.
>
> This might be a distracting aside, but could you comment on the idea
> that I think Stefan mentioned previously: that the native compiler
> could use not the original source files, but the byte-compiled *.elc
> files as the "source". By the time those are compiled, all the
> dependencies are resolved one way or another, right? So the user won't
> need to suffer the same kind of warnings again.
>
> Do they contain the necessary information to do native-compile, and
> its various optimizations? If yes, are there any other difficulties
> associated with such an approach?
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: native-comp-async-report-warnings-errors default value

[Andrea Corallo]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Hi Andrea,
>
> On 20.12.2021 11:29, Andrea Corallo wrote:
>> Stefan Kangas <stefankangas@gmail.com> writes:
>> 
>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>
>>>>> When I said "by popular demand", I meant that.  Just your own voice is
>>>>> not enough, IMO.
>>>
>>> I have now reviewed this thread, and changing the default from nil to
>>> silent has the support from Robert Pluim, Stefan Kangas, Lars
>>> Ingebrigtsen, Andrea Corallo and Óscar Fuentes (5).
>>>
>>> For keeping the current default I count Eli Zaretskii (1).
>>>
>>> Neutral in this thread are T.V. Raman and Stefan Monnier (2).
>> FWIW please count me on the neutral side, I've no formed opinion on
>> this
>> ATM even if the more time is passing the more I tend to think that the
>> current default might be safer and/or beneficial on the long run.
>
> This might be a distracting aside, but could you comment on the idea
> that I think Stefan mentioned previously: that the native compiler
> could use not the original source files, but the byte-compiled *.elc
> files as the "source". By the time those are compiled, all the
> dependencies are resolved one way or another, right? So the user won't
> need to suffer the same kind of warnings again.
>
> Do they contain the necessary information to do native-compile, and
> its various optimizations? If yes, are there any other difficulties
> associated with such an approach?

Hi Dmitry,

this is not a trivial modification so I might easily miss some aspects
of it but...

Certanly bytecode ATM has no way to store declaration specifiers and
these are used for native compilation.  I guess we should at least
extend this first.

BR

  Andrea

Re: native-comp-async-report-warnings-errors default value

[Dmitry Gutov]

Hi Andrea,

On 24.12.2021 12:53, Andrea Corallo wrote:
> this is not a trivial modification so I might easily miss some aspects
> of it but...
> 
> Certanly bytecode ATM has no way to store declaration specifiers and
> these are used for native compilation.  I guess we should at least
> extend this first.

Thanks for the answer, I really wanted at least a high-level 
understanding of this point. I wouldn't presume to ask you to work on 
this, but maybe some of the others here who also complained about the 
warnings, would be interested in taking the initiative?

Regarding declaration specifiers, I think the new (declare (modes ...)) 
feature had the same problem.

Not sure how it was solved (or whether it was solved at all).

Re: native-comp-async-report-warnings-errors default value

[Andrea Corallo]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Hi Andrea,
>
> On 24.12.2021 12:53, Andrea Corallo wrote:
>> this is not a trivial modification so I might easily miss some aspects
>> of it but...
>> Certanly bytecode ATM has no way to store declaration specifiers and
>> these are used for native compilation.  I guess we should at least
>> extend this first.
>
> Thanks for the answer, I really wanted at least a high-level
> understanding of this point. I wouldn't presume to ask you to work on
> this, but maybe some of the others here who also complained about the
> warnings, would be interested in taking the initiative?
>
> Regarding declaration specifiers, I think the new (declare (modes
> ...)) feature had the same problem.
>
> Not sure how it was solved (or whether it was solved at all).

I guess the mode declaration has affect during byte compilation so it
should be fine.  The issue is for other declarations that are taking
effect afterwards in the native compilation pipeline.

As the bytecompiler pipeline was always assumed to be the only and last
compilation step, bytecode is ATM not designed to retain these
information.  I'm sure it's extensible somehow but we probably need some
advise on what's the best way to approach this.

BR

  Andrea

Re: native-comp-async-report-warnings-errors default value

[Dmitry Gutov]

On 25.12.2021 13:53, Andrea Corallo wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Hi Andrea,
>>
>> On 24.12.2021 12:53, Andrea Corallo wrote:
>>> this is not a trivial modification so I might easily miss some aspects
>>> of it but...
>>> Certanly bytecode ATM has no way to store declaration specifiers and
>>> these are used for native compilation.  I guess we should at least
>>> extend this first.
>>
>> Thanks for the answer, I really wanted at least a high-level
>> understanding of this point. I wouldn't presume to ask you to work on
>> this, but maybe some of the others here who also complained about the
>> warnings, would be interested in taking the initiative?
>>
>> Regarding declaration specifiers, I think the new (declare (modes
>> ...)) feature had the same problem.
>>
>> Not sure how it was solved (or whether it was solved at all).
> 
> I guess the mode declaration has affect during byte compilation so it
> should be fine.  The issue is for other declarations that are taking
> effect afterwards in the native compilation pipeline.

It has an effect at runtime: Emacs needs to look up those properties 
after the byte code is evaluated. That's why .elc files have additional 
forms added which basically call 'function-put' (as set up in 
defun-declarations-alist).

But...

> As the bytecompiler pipeline was always assumed to be the only and last
> compilation step, bytecode is ATM not designed to retain these
> information.  I'm sure it's extensible somehow but we probably need some
> advise on what's the best way to approach this.

...I suppose you might want to access that information without 
evaluating said additional byte code forms either.

Or could it evaluate them anyway? If native compilation happens after 
the code is loaded, the symbols will have the necessary properties then.

Re: native-comp-async-report-warnings-errors default value

[Andrea Corallo]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 25.12.2021 13:53, Andrea Corallo wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> Hi Andrea,
>>>
>>> On 24.12.2021 12:53, Andrea Corallo wrote:
>>>> this is not a trivial modification so I might easily miss some aspects
>>>> of it but...
>>>> Certanly bytecode ATM has no way to store declaration specifiers and
>>>> these are used for native compilation.  I guess we should at least
>>>> extend this first.
>>>
>>> Thanks for the answer, I really wanted at least a high-level
>>> understanding of this point. I wouldn't presume to ask you to work on
>>> this, but maybe some of the others here who also complained about the
>>> warnings, would be interested in taking the initiative?
>>>
>>> Regarding declaration specifiers, I think the new (declare (modes
>>> ...)) feature had the same problem.
>>>
>>> Not sure how it was solved (or whether it was solved at all).
>> I guess the mode declaration has affect during byte compilation so
>> it
>> should be fine.  The issue is for other declarations that are taking
>> effect afterwards in the native compilation pipeline.
>
> It has an effect at runtime: Emacs needs to look up those properties
> after the byte code is evaluated. That's why .elc files have
> additional forms added which basically call 'function-put' (as set up
> in defun-declarations-alist).

Indeed it has effect in the runtime.  But as you say this is because the
byte compiler generates different code for that (in this case a top
level form).  In the case of the native compiler we'd need to store and
reuse a bunch of information for following native compilation that has
to happen after.

> But...
>
>> As the bytecompiler pipeline was always assumed to be the only and last
>> compilation step, bytecode is ATM not designed to retain these
>> information.  I'm sure it's extensible somehow but we probably need some
>> advise on what's the best way to approach this.
>
> ...I suppose you might want to access that information without
> evaluating said additional byte code forms either.
>
> Or could it evaluate them anyway? If native compilation happens after
> the code is loaded, the symbols will have the necessary properties
> then.

Maybe a sufficient solution is an ad hoc local variable emitted (when
necessary) in the .elc file with like an a-list function -> declaration
specifiers we are interested in?

  Andrea

Re: native-comp-async-report-warnings-errors default value

[Dmitry Gutov]

On 30.12.2021 11:37, Andrea Corallo wrote:

> Indeed it has effect in the runtime.  But as you say this is because the
> byte compiler generates different code for that (in this case a top
> level form).  In the case of the native compiler we'd need to store and
> reuse a bunch of information for following native compilation that has
> to happen after.

Store in .elc files, I take it.

>> But...
>>
>>> As the bytecompiler pipeline was always assumed to be the only and last
>>> compilation step, bytecode is ATM not designed to retain these
>>> information.  I'm sure it's extensible somehow but we probably need some
>>> advise on what's the best way to approach this.
>>
>> ...I suppose you might want to access that information without
>> evaluating said additional byte code forms either.
>>
>> Or could it evaluate them anyway? If native compilation happens after
>> the code is loaded, the symbols will have the necessary properties
>> then.
> 
> Maybe a sufficient solution is an ad hoc local variable emitted (when
> necessary) in the .elc file with like an a-list function -> declaration
> specifiers we are interested in?

I was even going to suggest that you would parse those (byte-code ...) 
forms in compiled files -- as long as they actually vary very little, it 
could be handled by a small interpreter.

But maybe we could keep those forms uncompiled without a significant 
performance downside? Someone could benchmark that. Then the .elc files 
would just contain (function-put ...) on top-level instead.

Or if you really need the declarations available before the 
corresponding functions are defined (I don't know if you compile every 
encountered function right away, or wait until the whole file is 
parsed), the order of forms in .elc files could be swapped: first 
property declaration, then definition.