From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#39529: 28.0.50; Metahelp does not contain help text Date: Tue, 18 Feb 2020 19:56:59 +0000 Message-ID: References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> <83blq7d06n.fsf@gnu.org> <59be714f-1b52-a068-70c8-3204cf016ca2@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="104004"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 39529@debbugs.gnu.org, federicotedin@gmail.com To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 18 20:58:22 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j490d-000QpD-RK for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 18 Feb 2020 20:58:19 +0100 Original-Received: from localhost ([::1]:41296 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j490c-0002Ov-Rq for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 18 Feb 2020 14:58:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42687) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j490N-0002Jy-IP for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 14:58:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j490M-0003GB-B5 for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 14:58:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35336) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j490M-0003Fv-7g for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 14:58:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j490M-0002dk-6W for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 14:58:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 Feb 2020 19:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39529 X-GNU-PR-Package: emacs Original-Received: via spool by 39529-submit@debbugs.gnu.org id=B39529.158205586210119 (code B ref 39529); Tue, 18 Feb 2020 19:58:02 +0000 Original-Received: (at 39529) by debbugs.gnu.org; 18 Feb 2020 19:57:42 +0000 Original-Received: from localhost ([127.0.0.1]:41309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4902-0002d9-CG for submit@debbugs.gnu.org; Tue, 18 Feb 2020 14:57:42 -0500 Original-Received: from mail-ot1-f50.google.com ([209.85.210.50]:45090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4901-0002cx-9F for 39529@debbugs.gnu.org; Tue, 18 Feb 2020 14:57:41 -0500 Original-Received: by mail-ot1-f50.google.com with SMTP id 59so20764595otp.12 for <39529@debbugs.gnu.org>; Tue, 18 Feb 2020 11:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/QYaqtjw6WWWB635Z4aqbETkmqB1KZlRU8z9KEgGXoE=; b=CQeyCk5UKvuFvuSG+LNRXPLBrGY0EeBSauAuijFWv31rNcrR4NMQ9uDi4yfP3frhkq jkhcbbCylWDboAQJM77DCctASeYjllGQpG+Od/5tkFLyDWdsIQsRNgTRAJZrLu0irTMc mYR5YKMK4bmLxEdI6QQYUWFlnbgmQikqc17VlrL879fVhV2PJGNdxVUL6q6DS4AJlQpg cTfxDSTGCQjVCJF3gxGU1ZBK16y6INN7F91YFgAfZCO10Qq8qth5B5wCYq8SHP1xbLrz csD1HiXZGpqNI71thuRgUu2rsQQS55MdtHh1g4AK3746XEiWiIxa6di2kXOk76bEVIxv +xxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/QYaqtjw6WWWB635Z4aqbETkmqB1KZlRU8z9KEgGXoE=; b=MDjDnwlPOodyDJpKDPLXigOUBjTcyhRWS77kmNd5ZmpOclbSpj4Qh6PVbqtDyJj7oC cz2myQIGAfwKDtJcrGxjrOm0UAF/nGrRHQG/l6Cn9UO8B28MMf1w4T18dxo9EgGHULm9 UPWNx4BnmGmqkU2ZPKB+M8pTpT/Gy3d84C9v+rPjTsGYuxEMaobkLOXAQjl3euDlTOpN Cy89bu42omhkPCBpAOLWPys7qR25FEZliBw+d5OQ+Hok6BPHr0dA+rD7sz9bVwF3Rmuz rDBY2Zg/B3giC00rztBSrGg3OepHOmQ7QhEm0O7+dI3PmfUxOS/X0jN5DV8cxPMlYtWv sXDg== X-Gm-Message-State: APjAAAUktBxsnFzyiSNZQJ5ahMr/NdMLHQ/BFFV/WMagX80/jectfwTC yM8UiGWXe7AMJwaCYTwJON+6tkfmosN1dJc4NXw= X-Google-Smtp-Source: APXvYqxD/iNP9tHnvaE34sik/8SXRPICIj8ALeIhqMwpibWA94SbaOLVPv81Z23TiCse+NpwTxWO+4b25+vLzZIdipA= X-Received: by 2002:a9d:1c9c:: with SMTP id l28mr16565546ota.210.1582055855584; Tue, 18 Feb 2020 11:57:35 -0800 (PST) In-Reply-To: <59be714f-1b52-a068-70c8-3204cf016ca2@cs.ucla.edu> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:176210 Archived-At: On Sun, Feb 16, 2020 at 7:43 PM Paul Eggert 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.