unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Pip Cet <pipcet@gmail.com>
To: 39529@debbugs.gnu.org, eggert@cs.ucla.edu, federicotedin@gmail.com
Cc: 39529-done@debbugs.gnu.org
Subject: bug#39529: 28.0.50; Metahelp does not contain help text
Date: Sun, 16 Feb 2020 16:51:38 +0000	[thread overview]
Message-ID: <CAOqdjBdXN9_+fFC7ehLwCZdDcTvYRVCquBNLhPjt4i7vVkwUmQ@mail.gmail.com> (raw)
In-Reply-To: <e1dae7d6-376c-a9f5-b0b6-4ade20dca59b@cs.ucla.edu>

On Sat, Feb 15, 2020 at 11:26 PM Paul Eggert <eggert@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.





  parent reply	other threads:[~2020-02-16 16:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-09 19:06 bug#39529: 28.0.50; Metahelp does not contain help text Federico Tedin
2020-02-09 19:22 ` Eli Zaretskii
2020-02-09 19:34   ` Eli Zaretskii
2020-02-15 23:25     ` Paul Eggert
2020-02-16 15:35       ` Eli Zaretskii
2020-02-16 16:51       ` Pip Cet [this message]
2020-02-16 19:43         ` Paul Eggert
2020-02-18 19:56           ` Pip Cet
2020-02-19  1:21             ` Paul Eggert
2020-02-19  2:34               ` Pip Cet
2020-02-19  9:00                 ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOqdjBdXN9_+fFC7ehLwCZdDcTvYRVCquBNLhPjt4i7vVkwUmQ@mail.gmail.com \
    --to=pipcet@gmail.com \
    --cc=39529-done@debbugs.gnu.org \
    --cc=39529@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=federicotedin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).