GNU bug report logs - #39529
28.0.50; Metahelp does not contain help text

Previous Next

Full log

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

From: Pip Cet <pipcet <at> gmail.com>
To: 39529 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, federicotedin <at> gmail.com
Cc: Eli Zaretskii <eliz <at> gnu.org>, 39529-done <at> debbugs.gnu.org
Subject: Re: bug#39529: 28.0.50; Metahelp does not contain help text
Date: Sun, 16 Feb 2020 16:51:38 +0000

On Sat, Feb 15, 2020 at 11:26 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> > I suspect the sxhash changes on Jan 7.  This problem started happening
> > in that day's build.
>
> Right you are. The problem was Emacs was using a hash table to unify identical
> Lisp compiled objects when purecopying them, even though their doc strings were
> not set up yet (and so were 0 placeholders that always compared equal). Formerly
> this bug was masked because sxhash simply returned the objects' hashed
> addresses, but the January 7 changes unveiled the bug. I install the attached
> patch to fix the problem.

That works as a quick fix, but it's not perfectly correct, since it
relies on different objects having different hashes, and they might,
by pure chance, have the same hash.

We need to fix the underlying issue, or at least go for the correct
"quick fix", which is to make equal = eq for bytecode objects (this is
almost indistinguishable from the previous behavior, before
sxhash-equal was "fixed").

The pure-cons hash, and many other places, assume "equal" means
"equivalent" in some way. That's not true for bytecode objects, where
a function always returning `nil' can be equal to one always returning
`t'.

And I still suspect many other people have made the same "mistake" as
I, of assuming the previous behavior of equal-based hashes for markers
and overlays was guaranteed. To recap, the January 7 changes broke
code that uses markers or overlays as hash keys (or as components of
hash keys) in equal-based hash tables; before the changes, it was safe
to do so. After the changes, it's only safe to do if the character
positions don't change between storage and lookup, and there's no hint
at what might be happening.

In summary, I still think the right fix is not to make equal look at
more state than sxhash-equal used to, particularly for Emacs 27. We've
now seen that the January 7 changes cause follow-up bugs, such as this
one, so maybe it's time to reconsider what the right thing to do is
here.

Previous Next

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