bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode

[Eli Zaretskii <eliz@gnu.org>]

> From: Pip Cet <pipcet@gmail.com>
> Date: Sat, 27 Feb 2021 17:15:20 +0000
> Cc: Andrea Corallo <akrl@sdf.org>, 46670@debbugs.gnu.org, mauricio@collares.org
> 
> > especially after he
> > responded to your messages with sound reasons.
> 
> I take it you've read through the code, understood it all, and
> concluded the reasons were "sound", then?

I have my own ways of judging what people say and deciding when they
are sound and when they aren't.  If you want to question my judgment
as well, you are talking to the wrong guy.

> > Please understand that any other way, we'd lose Andrea and any other
> > volunteers who come to us with significant new features.
> 
> I have my own opinions about why Emacs attracts so few volunteers and
> drives away so many of those who might be.

You are welcome to step up to be the Emacs maintainer, and then act
according to your opinions.

> > What matters to me at this point is the end result.
> > Any issue that
> > causes mis-compilation of Lisp programs should be fixed, of course.
> > Issues that don't affect the natively-compiled code are much less
> > important, and as I explained, my tendency is to accept Andrea's
> > judgment on those.
> 
> There's a difference between "this issue doesn't affect
> natively-compiled code" (which makes it a non-issue, case 2 above) and
> "we don't know whether this issue affects natively-compiled code"
> (which emphatically does not, case 3 above). Evidence of absence and
> all that.

When there's evidence, there's no doubt, and such issues should be and
are taken care of.  Where there's no evidence, we trust the judgment
of the best experts we have, when they show (as they usually do) they
carefully considered the issue before expressing their opinions.  The
rest of us, if we don't agree with the expert judgment, get to work
harder to find the evidence.  There's no way around this.

> > > However, the task of proving that this actually results in a
> > > Lisp-to-machine-code bug is, in general, too much to expect the
> > > initial discoverer to perform.
> >
> > The initial discoverer doesn't have to do that, it's enough to raise
> > the issue.
> 
> Andrea has stated that if there's no reproducer, he doesn't consider
> the issue a bug. So "raising the issue" would do, according to the
> rules he proposed, precisely nothing.

I suggest that you consider deeds before you consider words.  I
challenge you to find any response from Andrea where he dismissed any
report without first considering it seriously and responding to the
report with his reasoning.

> IIUC, you want me to raise future issues and wait for them to be
> dismissed rather than complaining, as I am, about the mere
> announcement that they will be? That's certainly something I can do,
> and resolving that I'll do that would actually be a good result of
> this discussion.
> 
> > did consider it and did fix a couple of issues you brought up that he
> > thought were worth fixing.
> 
> Yes. And he said he wouldn't do so in future, for issues of this category.

See above.