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

[Pip Cet <pipcet@gmail.com>]

On Sat, Feb 27, 2021 at 6:41 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > 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.

You're using "sound" to mean "superficially correct". I understood it
to have its mathematical (and legal) meaning, "irrefutably correct".

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

There's a whole spectrum between "we shouldn't fly into that mountain"
and "let me take the controls".

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

Let's see how this plays out.