bug#39529: 28.0.50; Metahelp does not contain help text

[Pip Cet <pipcet@gmail.com>]

On Sun, Feb 16, 2020 at 7:43 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 2/16/20 8:51 AM, Pip Cet wrote:
> > it relies on different objects having different hashes, and they might,
> > by pure chance, have the same hash.

Just to be clear about that: I was wrong here, and had misread the
code. It does not, in fact, rely on arbitrary different objects having
different hashes; it relies on different vectors having different
XHASHes, which you correctly point out they do, on practical targets.

> That could happen only if two Lisp vector addresses disagree only in the
> high-order bit during dumping while on a USE_LSB_TAG platform, something that I
> didn't think possible on practical Emacs targets. However, the potential problem
> is easy enough to work around; I installed the attached.

You're absolutely correct.

> > 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").
>
> Give the attached patch I hope no such quick fix is needed.

Let me turn around that argument: if we rely on the precise
definitions of XHASH etc. that were in place prior to the January
changes, no "quick fix" was needed; it was simply the case that the
predicate used by hash tables created with :test equal diverged from
the built-in `equal' predicate in one more way than was already
documented. (Those documented deviations are that mutations of hash
keys won't cause rehashing, and that equal will sometimes signal for
(equal a b) but not for (equal b a)).

> For what it's worth, the patched code is similar to what Fautoload does; so if
> there's something wrong here, a similar wrongness has likely been present in
> Fautoload for some time.

Thanks for pointing that out, I wasn't aware of it.

> > 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'.
>
> Could you give an example of this? When I byte-compiled this:

(defun f () (let ((x '(#1=(nil) . #1#)))
          (eq (car x) (cdr x))))
(defun g () (let ((x '((nil) . (nil)))
          (eq (car x) (cdr x))))

That's somewhat contrived; more realistic examples where this might
actually be a problem would use string properties.

> > the right fix is not to make equal look at
> > more state than sxhash-equal used to, particularly for Emacs 27.
>
> That would indeed make 'equal' and 'sxhash-equal' consistent. But wouldn't it
> potentially break a different set of user programs, that (say) rely on 'equal'
> returning nil when markers point to different locations?

You're right, that wouldn't work.

I'll propose one more thing, which sounds horrible at first but might
be the least horrible option: accept that `equal', the function, and
`:test equal', the hash table predicate, have diverged significantly
already. Keep them separate but similar in Emacs 27, and introduce
more useful hash table predicates in Emacs 28.

That would allow us to restore the previous behavior for Emacs 27,
document the inconsistency there, fix the pdumper bug that caused the
original bug report, remove the hacky XHASH implementation dependency
from Fautoload and read1, and return to cleaner semantics for Emacs
28.

> So I'd be leery about messing with Emacs 27 in this area.

I think we already have messed with Emacs 27 in ways that we shouldn't have.

> (To my mind a better fix would be to introduce the notion of immutability, and
> for sxhash-equal to inspect only the immutable parts of key contents. But now
> it's time for me to duck and run....)

immutably-equal would indeed be one hash table predicate that I'd like to see.