bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[No Wayman]

Apologies for the vague report.
I've been unable to track down a reliable reproduction recipe.
Tonight, when evaluating the following:

(comp--native-compile (lambda nil) nil nil)

The following error is signaled:

Debugger entered--Lisp error: (native-compiler-error "Invalid hash 
table test: tab-bar--auto-width-hash-test\n\nError: error 
(\"Invalid hash table test\" tab-bar--auto-width-hash-test)\n 
read(#<buffer  *load*>)\n 
load-with-code-conversion(\"/tmp/emacs-int-comp-comp-lambda-AXDHaA-YLR7FG.el\" 
\"/tmp/emacs-int-comp-comp-lambda-AXDHaA-YLR7FG.el\" nil t)\n 
command-line-1((\"-l\" 
\"/tmp/emacs-int-comp-comp-lambda-AXDHaA-YLR7FG.el\"))\n 
command-line()\n  normal-top-level()\n")

I saw the same several days ago when using trying to `macroexpand' 
a form. 


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.40, cairo version 1.18.0) of 2024-01-22 built on laptop
Repository revision: f821ac29e0cf69316d6c721bafe9b749b47a6db3
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 
11.0.12101011
System Description: Arch Linux

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Juri Linkov]

> Debugger entered--Lisp error:
> (native-compiler-error "Invalid hash table test:
> tab-bar--auto-width-hash-test

Yesterday I was seeing exactly the same error
until recompiled and restarted Emacs.

Please confirm that bootstrap fixed this problem for you.

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Juri Linkov]

close 68668 30.0.50
thanks

>> Debugger entered--Lisp error:
>> (native-compiler-error "Invalid hash table test:
>> tab-bar--auto-width-hash-test
>
> Yesterday I was seeing exactly the same error
> until recompiled and restarted Emacs.
>
> Please confirm that bootstrap fixed this problem for you.

I suppose everything is ok now, so closing.

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[iarchivedmywholelife]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

Did not have time to test it today.
-------- Original message --------From: Juri Linkov <juri@linkov.net> Date: 1/24/24  3:01 AM  (GMT-05:00) To: No Wayman <iarchivedmywholelife@gmail.com> Cc: 68668@debbugs.gnu.org Subject: Re: bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test close 68668 30.0.50thanks>> Debugger entered--Lisp error:>> (native-compiler-error "Invalid hash table test:>> tab-bar--auto-width-hash-test>> Yesterday I was seeing exactly the same error> until recompiled and restarted Emacs.>> Please confirm that bootstrap fixed this problem for you.I suppose everything is ok now, so closing.

[-- Attachment #2: Type: text/html, Size: 1014 bytes --]

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Juri Linkov <juri@linkov.net> writes:

> close 68668 30.0.50
> thanks
>
>>> Debugger entered--Lisp error:
>>> (native-compiler-error "Invalid hash table test:
>>> tab-bar--auto-width-hash-test
>>
>> Yesterday I was seeing exactly the same error
>> until recompiled and restarted Emacs.
>>
>> Please confirm that bootstrap fixed this problem for you.
>
> I suppose everything is ok now, so closing.

EMBA is still hitting this[1] and I can reproduce it here on
Debian testing with just:

  git clone https://git.savannah.gnu.org/git/emacs.git
  cd emacs
  make bootstrap
  make test/src/keymap-tests.log

1. https://emba.gnu.org/emacs/emacs/-/jobs/80161

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Juri Linkov]

reopen 68668
tags 68668 confirmed
thanks

>>>> Debugger entered--Lisp error:
>>>> (native-compiler-error "Invalid hash table test:
>>>> tab-bar--auto-width-hash-test
>>>
> EMBA is still hitting this[1] and I can reproduce it here on
> Debian testing with just:
>
>   git clone https://git.savannah.gnu.org/git/emacs.git
>   cd emacs
>   make bootstrap
>   make test/src/keymap-tests.log
>
> 1. https://emba.gnu.org/emacs/emacs/-/jobs/80161

Thanks for the reference to the failing test case
'keymap-test-duplicate-definitions'.  So now reopening.

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

john muhl via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

Hi John,

> EMBA is still hitting this[1] and I can reproduce it here on
> Debian testing with just:
>
>   git clone https://git.savannah.gnu.org/git/emacs.git
>   cd emacs
>   make bootstrap
>   make test/src/keymap-tests.log
>
> 1. https://emba.gnu.org/emacs/emacs/-/jobs/80161

ATM, we have problems on emba with git mirroring. The job you are
referring to ran on top of:

--8<---------------cut here---------------start------------->8---
commit 87cf30fba37346a179c6307a29d5d39b39311cef
Author: Basil L. Contovounesios <contovob@tcd.ie>
Date:   Fri Jan 19 13:50:29 2024 +0100

    Further shrink eglot--{}
--8<---------------cut here---------------end--------------->8---

We are working on bringing emba back to recent.

Best regards, Michael.

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Michael Albinus <michael.albinus@gmx.de> writes:

> john muhl via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
>
> Hi John,
>
>> EMBA is still hitting this[1] and I can reproduce it here on
>> Debian testing with just:
>>
>>   git clone https://git.savannah.gnu.org/git/emacs.git
>>   cd emacs
>>   make bootstrap
>>   make test/src/keymap-tests.log
>>
>> 1. https://emba.gnu.org/emacs/emacs/-/jobs/80161
>
> ATM, we have problems on emba with git mirroring. The job you are
> referring to ran on top of:
>
> commit 87cf30fba37346a179c6307a29d5d39b39311cef
> Author: Basil L. Contovounesios <contovob@tcd.ie>
> Date:   Fri Jan 19 13:50:29 2024 +0100
>
>     Further shrink eglot--{}
>
> We are working on bringing emba back to recent.
>
> Best regards, Michael.

My mistake.

Anyway I still see it in my own tests today with a8cfe3bda8b.
Bisect says the first commit to cause the failure in
keymap-tests is 54d3de64e19.

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Mekeor Melire]

Hello, I just wanted to share a work-around for this bug, even though it
is probably bad for performance:

	(setopt native-comp-enable-subr-trampolines nil)

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Eli Zaretskii]

> From: Mekeor Melire <mekeor@posteo.de>
> Date: Mon, 29 Jan 2024 22:53:45 +0000
> 
> Hello, I just wanted to share a work-around for this bug, even though it
> is probably bad for performance:
> 
> 	(setopt native-comp-enable-subr-trampolines nil)

Can someone please post a recipe for reproducing this?  Does this
happen if you say "make bootstrap"?

Adding Andrea in case he has some comments or ideas.

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mekeor Melire <mekeor@posteo.de>
>> Date: Mon, 29 Jan 2024 22:53:45 +0000
>> 
>> Hello, I just wanted to share a work-around for this bug, even though it
>> is probably bad for performance:
>> 
>> 	(setopt native-comp-enable-subr-trampolines nil)
>
> Can someone please post a recipe for reproducing this?  Does this
> happen if you say "make bootstrap"?

This most reliable way to reproduce it for me is:

  git clone https://git.savannah.gnu.org/git/emacs.git
  cd emacs
  make bootstrap
  make test/src/keymap-tests.log

It reproduces on 32 & 64bit systems, x86_64, armv7l and aarch64.
The problem first shows up with keymap-tests in 54d3de64e19.
Attached is the keymap-tests.log.


[-- Attachment #2: keymap-tests.log --]
[-- Type: text/plain, Size: 5427 bytes --]

Running 46 tests (2024-01-29 19:58:55-0600, selector ‘(not (or (tag :expensive-test) (tag :unstable)))’)
   passed   1/46  describe-buffer-bindings/header-in-current-buffer (0.134382 sec)
   passed   2/46  describe-buffer-bindings/menu-item-filter-hide-binding (0.109526 sec)
   passed   3/46  describe-buffer-bindings/menu-item-filter-show-binding (0.074882 sec)
   passed   4/46  describe-buffer-bindings/returns-nil (0.111174 sec)
   passed   5/46  help--describe-vector/bug-9293-one-shadowed-in-range (0.000290 sec)
   passed   6/46  help--describe-vector/bug-9293-same-command-does-not-shadow (0.000174 sec)
   passed   7/46  keymap---get-keyelt/runs-menu-item-filter (0.000141 sec)
   passed   8/46  keymap--key-description (0.000154 sec)
   passed   9/46  keymap-copy-keymap/is-equal (0.000111 sec)
   passed  10/46  keymap-copy-keymap/is-not-eq (0.000098 sec)
   passed  11/46  keymap-define-key/keyboard-macro (0.000103 sec)
   passed  12/46  keymap-define-key/keymap (0.000101 sec)
   passed  13/46  keymap-define-key/lambda (0.000126 sec)
   passed  14/46  keymap-define-key/menu-item (0.000103 sec)
   passed  15/46  keymap-define-key/undefined (0.000105 sec)
   passed  16/46  keymap-keymap-parent (0.000120 sec)
   passed  17/46  keymap-keymapp (0.000116 sec)
   passed  18/46  keymap-lookup-key (0.000110 sec)
   passed  19/46  keymap-lookup-key/list-of-keymaps (0.000121 sec)
   passed  20/46  keymap-lookup-key/menu-non-symbol (0.000102 sec)
   passed  21/46  keymap-lookup-key/mixed-case (0.000157 sec)
   passed  22/46  keymap-lookup-key/mixed-case-multibyte (0.000159 sec)
   passed  23/46  keymap-lookup-key/too-long (0.000178 sec)
   passed  24/46  keymap-lookup-keymap/with-spaces (0.000115 sec)
   passed  25/46  keymap-lookup-keymap/with-spaces-multibyte (0.000112 sec)
   passed  26/46  keymap-lookup-keymap/with-spaces-multibyte-lang-env (0.005449 sec)
   passed  27/46  keymap-make-keymap (0.000166 sec)
   passed  28/46  keymap-make-sparse-keymap (0.000114 sec)
   passed  29/46  keymap-removal (0.000226 sec)
   passed  30/46  keymap-removal-inherit (0.000151 sec)
   passed  31/46  keymap-set-after-menus (0.000225 sec)
   passed  32/46  keymap-set-consistency (0.000454 sec)
   passed  33/46  keymap-store_in_keymap-XFASTINT-on-non-characters (0.000114 sec)
Test keymap-test-duplicate-definitions backtrace:
  signal(native-compiler-error ((lambda (arg540 &rest arg541) (let ((f
  comp--native-compile((lambda (arg540 &rest arg541) (let ((f #'messag
  comp-trampoline-compile(message)
  comp-subr-trampoline-install(message)
  fset(message #<subr message>)
  (unwind-protect (progn (fset 'message vnew) (let* ((fn-517 #'string-
  (let* ((vnew #'(lambda (fmt &rest args) (setq msg (apply #'format fm
  (let ((msg "")) (let* ((vnew #'(lambda (fmt &rest args) (setq msg (a
  (closure (keymap-tests-major-mode-abbrev-table keymap-tests-major-mo
  #f(compiled-function () #<bytecode 0xf94f9b508c27f1e>)()
  handler-bind-1(#f(compiled-function () #<bytecode 0xf94f9b508c27f1e>
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name keymap-test-duplicate-definitions :do
  ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
  ert-run-tests((not (or (tag :expensive-test) (tag :unstable))) #f(co
  ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable)))
  ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
  eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
  command-line-1(("-L" ":." "-l" "ert" "-l" "src/keymap-tests.el" "--e
  command-line()
  normal-top-level()
Test keymap-test-duplicate-definitions condition:
    (native-compiler-error
     (lambda (arg540 &rest arg541) (let ((f ...)) (apply f arg540 arg541)))
     "Invalid hash table test: tab-bar--auto-width-hash-test\n\nError: error (\"Invalid hash table test\" tab-bar--auto-width-hash-test)\n  read(#<buffer  *load*>)\n  load-with-code-conversion(\"/tmp/emacs-int-comp-subr--trampoline-6d657373616765_message_0-Yuf1Hq.el\" \"/tmp/emacs-int-comp-subr--trampoline-6d657373616765_message_0-Yuf1Hq.el\" nil t)\n  command-line-1((\"-l\" \"/tmp/emacs-int-comp-subr--trampoline-6d657373616765_message_0-Yuf1Hq.el\"))\n  command-line()\n  normal-top-level()\n")
   FAILED  34/46  keymap-test-duplicate-definitions (1.104168 sec) at src/keymap-tests.el:467
   passed  35/46  keymap-test-lookups (0.000334 sec)
   passed  36/46  keymap-text-char-description (0.000365 sec)
   passed  37/46  keymap-unset-test-remove-and-inheritance (0.000344 sec)
   passed  38/46  keymap-where-is-internal (0.000930 sec)
   passed  39/46  keymap-where-is-internal/advertised-binding (0.000177 sec)
   passed  40/46  keymap-where-is-internal/advertised-binding-respect-remap (0.001038 sec)
   passed  41/46  keymap-where-is-internal/firstonly-t (0.000126 sec)
   passed  42/46  keymap-where-is-internal/menu-item (0.001507 sec)
   passed  43/46  keymap-where-is-internal/preferred-modifier-is-a-string (0.001594 sec)
   passed  44/46  keymap-where-is-internal/remap (0.001070 sec)
   passed  45/46  keymap-where-is-internal/shadowed (0.001270 sec)
   passed  46/46  test-non-key-events (0.002199 sec)

Ran 46 tests, 45 results as expected, 1 unexpected (2024-01-29 19:58:57-0600, 1.877300 sec)

1 unexpected results:
   FAILED  keymap-test-duplicate-definitions

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Andrea Corallo]

john muhl <jm@pub.pink> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Mekeor Melire <mekeor@posteo.de>
>>> Date: Mon, 29 Jan 2024 22:53:45 +0000
>>> 
>>> Hello, I just wanted to share a work-around for this bug, even though it
>>> is probably bad for performance:
>>> 
>>> 	(setopt native-comp-enable-subr-trampolines nil)
>>
>> Can someone please post a recipe for reproducing this?  Does this
>> happen if you say "make bootstrap"?
>
> This most reliable way to reproduce it for me is:
>
>   git clone https://git.savannah.gnu.org/git/emacs.git
>   cd emacs
>   make bootstrap
>   make test/src/keymap-tests.log
>
> It reproduces on 32 & 64bit systems, x86_64, armv7l and aarch64.
> The problem first shows up with keymap-tests in 54d3de64e19.
> Attached is the keymap-tests.log.

I can reproduce this recipe, smells of some some function being moked
that the native compiler needs in order to work.  I'll try to have a
look.

  Andrea

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> john muhl <jm@pub.pink> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Mekeor Melire <mekeor@posteo.de>
>>>> Date: Mon, 29 Jan 2024 22:53:45 +0000
>>>>
>>>> Hello, I just wanted to share a work-around for this bug, even though it
>>>> is probably bad for performance:
>>>>
>>>> 	(setopt native-comp-enable-subr-trampolines nil)
>>>
>>> Can someone please post a recipe for reproducing this?  Does this
>>> happen if you say "make bootstrap"?
>>
>> This most reliable way to reproduce it for me is:
>>
>>   git clone https://git.savannah.gnu.org/git/emacs.git
>>   cd emacs
>>   make bootstrap
>>   make test/src/keymap-tests.log
>>
>> It reproduces on 32 & 64bit systems, x86_64, armv7l and aarch64.
>> The problem first shows up with keymap-tests in 54d3de64e19.
>> Attached is the keymap-tests.log.
>
> I can reproduce this recipe, smells of some some function being moked
> that the native compiler needs in order to work.  I'll try to have a
> look.
>
>   Andrea

Okay investigation in progress, here a minimal reproducer:

(describe-buffer-bindings (current-buffer))
(comp-trampoline-compile 'message)

What is going on is that for some reason after calling
'describe-buffer-bindings' an hash table with
'tab-bar--auto-width-hash-test' as test is leaked into the compilation
environment.

As this is passed to the spawned process we fail as there
'tab-bar--auto-width-hash-test' is not defined.

  Andrea

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> john muhl <jm@pub.pink> writes:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>>> From: Mekeor Melire <mekeor@posteo.de>
>>>>> Date: Mon, 29 Jan 2024 22:53:45 +0000
>>>>>
>>>>> Hello, I just wanted to share a work-around for this bug, even though it
>>>>> is probably bad for performance:
>>>>>
>>>>> 	(setopt native-comp-enable-subr-trampolines nil)
>>>>
>>>> Can someone please post a recipe for reproducing this?  Does this
>>>> happen if you say "make bootstrap"?
>>>
>>> This most reliable way to reproduce it for me is:
>>>
>>>   git clone https://git.savannah.gnu.org/git/emacs.git
>>>   cd emacs
>>>   make bootstrap
>>>   make test/src/keymap-tests.log
>>>
>>> It reproduces on 32 & 64bit systems, x86_64, armv7l and aarch64.
>>> The problem first shows up with keymap-tests in 54d3de64e19.
>>> Attached is the keymap-tests.log.
>>
>> I can reproduce this recipe, smells of some some function being moked
>> that the native compiler needs in order to work.  I'll try to have a
>> look.
>>
>>   Andrea
>
> Okay investigation in progress, here a minimal reproducer:
>
> (describe-buffer-bindings (current-buffer))
> (comp-trampoline-compile 'message)
>
> What is going on is that for some reason after calling
> 'describe-buffer-bindings' an hash table with
> 'tab-bar--auto-width-hash-test' as test is leaked into the compilation
> environment.
>
> As this is passed to the spawned process we fail as there
> 'tab-bar--auto-width-hash-test' is not defined.
>
>   Andrea


Okay something very wierd hash related is going on here:

If I evaluate:

(progn
  (describe-buffer-bindings (current-buffer))
  (require 'comp)
  (make-comp-data-container))

I get

#s(comp-data-container nil #s(hash-table test tab-bar--auto-width-hash-test))

In place of the expected

#s(comp-data-container nil #s(hash-table test comp-imm-equal-test))

Adding Mattias in Cc.

Thanks

  Andrea

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Okay something very wierd hash related is going on here:
>
> If I evaluate:
>
> (progn
>   (describe-buffer-bindings (current-buffer))
>   (require 'comp)
>   (make-comp-data-container))
>
> I get
>
> #s(comp-data-container nil #s(hash-table test tab-bar--auto-width-hash-test))
>
> In place of the expected
>
> #s(comp-data-container nil #s(hash-table test comp-imm-equal-test))

That's get_hash_table_user_test in fns.c which only keeps the first
occurrence of user-defined hash tests which have the same definition.
Pretty confusing, IMO.

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Mattias Engdegård]

31 jan. 2024 kl. 11.29 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> That's get_hash_table_user_test in fns.c which only keeps the first
> occurrence of user-defined hash tests which have the same definition.

Oops, sorry about that. Thank you for finding this anomaly!

It's indeed a bit unexpected. It doesn't affect hash table operations as such, only the output of `hash-table-test` and the print representation. However, this means that a hash table couldn't be deserialised under some circumstances, which is a problem.

A correction has been pushed (7e85311a911).

I'm still not really satisfied with the current implementation of user-defined tests. I have a patch which turns hash-table tests into Lisp objects but it seems to slow down basic operations for some reason which is why I haven't used it yet.

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Gerd Möllmann]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> A correction has been pushed (7e85311a911).

Probably dumb question: why not reuse an existing entry for a given
name?
     

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Mattias Engdegård]

31 jan. 2024 kl. 14.05 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> why not reuse an existing entry for a given name?

We mustn't violate invariants of existing hash-table objects when the test is redefined. Consider:

(define-hash-table-test 'mytest #'cmp1 #'hash1)
(setq h (make-hash-table :test 'mytest))
...
(define-hash-table-test 'mytest #'cmp2 #'hash2)
; h must still use cmp1 and hash1 at this point

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Gerd Möllmann]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 31 jan. 2024 kl. 14.05 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> why not reuse an existing entry for a given name?
>
> We mustn't violate invariants of existing hash-table objects when the
> test is redefined. Consider:
>
> (define-hash-table-test 'mytest #'cmp1 #'hash1)
> (setq h (make-hash-table :test 'mytest))
> ...
> (define-hash-table-test 'mytest #'cmp2 #'hash2)
> ; h must still use cmp1 and hash1 at this point

But that also means that we end up with two sorts of hash-tables that
behave differently, without us being able to tell them apart, because
hash-table-test returns 'mytest for both. I think I'd prefer if that
were not the case, and the redefinition would apply to both. If an old
hash-table then behaves stragely, I know what's up, and can empty it, if
it isn't still empty in the first place.

Just my 2 cents.

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Mattias Engdegård]

31 jan. 2024 kl. 14.34 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> But that also means that we end up with two sorts of hash-tables that
> behave differently, without us being able to tell them apart, because
> hash-table-test returns 'mytest for both.

This is how elisp hash tables worked in Emacs 29; I didn't change that part, I think.

> I think I'd prefer if that
> were not the case, and the redefinition would apply to both. If an old
> hash-table then behaves stragely, I know what's up, and can empty it, if
> it isn't still empty in the first place.

I'm not really happy with that sort of spooky action at a distance because it makes it too easy not only to introduce mysterious behaviour but also violate invariants that the C implementation relies upon for the management of an internal data structure.

That said, it is true that Lisp permits retroactive dynamism in several places even with the current design: the test and hash functions can both be redefined, and of course all code in Lisp is potentially impure and can change behaviour when its environment changes.

I still believe the current semantics cause fewer user headaches on balance. In any case, it probably should be documented in the `define-hash-table-test` doc string.

But you do raise an interesting point, thank you!

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Gerd Möllmann]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 31 jan. 2024 kl. 14.34 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> But that also means that we end up with two sorts of hash-tables that
>> behave differently, without us being able to tell them apart, because
>> hash-table-test returns 'mytest for both.
>
> This is how elisp hash tables worked in Emacs 29; I didn't change that
> part, I think.

That's true, and probably a good enough reason not to change it.

BTW, your fix also fixed keymap_tests.

bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Andrea Corallo <acorallo@gnu.org>,  john muhl <jm@pub.pink>,  Mekeor
>  Melire <mekeor@posteo.de>,  Eli Zaretskii <eliz@gnu.org>,
>   68668@debbugs.gnu.org,  Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 31 Jan 2024 15:44:25 +0100
> 
> BTW, your fix also fixed keymap_tests.

If there's a bug open for that, please close it, and thanks.

bug#68821: Native compile error when activating rectangle-mark-mode

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Andrea Corallo <acorallo@gnu.org>,  john muhl <jm@pub.pink>,  Mekeor
>>  Melire <mekeor@posteo.de>,  Eli Zaretskii <eliz@gnu.org>,
>>   68668@debbugs.gnu.org,  Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Wed, 31 Jan 2024 15:44:25 +0100
>> 
>> BTW, your fix also fixed keymap_tests.
>
> If there's a bug open for that, please close it, and thanks.

It's this one, so I'm closing it.

bug#68821: Native compile error when activating rectangle-mark-mode

[Johann Höchtl]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

I am using Emacs build
https://github.com/kiennq/emacs-build/releases/download/v30.221.20240118.9553d51/emacs-master-x86_64-full.zip

9553d51 may reference a savanah commit hash?

When invoking rectangle-mark-mode, either via M-x or via C-x <SPACE> I get
the following error message:

Error: error ("Invalid hash table test" tab-bar--auto-width-hash-test)
  read(#<buffer  *load*>)

load-with-code-conversion("c:/Users/HoechtlJ/AppData/Local/Temp/emacs-int-comp-subr--trampoline-726567696f6e2d626567696e6e696e67_region_beginning_0-hJjV22.el"
"c:/Users/HoechtlJ/AppData/Local/Temp/emacs-int-comp-subr--trampoline-726567696f6e2d626567696e6e696e67_region_beginning_0-hJjV22.el"
nil t)
  command-line-1(("-l"
"c:/Users/HoechtlJ/AppData/Local/Temp/emacs-int-comp-subr--trampoline-726567696f6e2d626567696e6e696e67_region_beginning_0-hJjV22.el"))
  command-line()
  normal-top-level()
Invalid hash table test: tab-bar--auto-width-hash-test

Tab-bar-mode is enabled. Do take note that rectangular selections eg. via
cua-mode do work.

I do not know if this is a Windows specific error, a packaging issue or a
general bug.

[-- Attachment #2: Type: text/html, Size: 1486 bytes --]

bug#68821: Native compile error when activating rectangle-mark-mode

[Eli Zaretskii]

merge 68821 68668
thanks

> From: Johann Höchtl <johann.hoechtl@gmail.com>
> Date: Tue, 30 Jan 2024 17:01:52 +0100
> 
> I am using Emacs build
> https://github.com/kiennq/emacs-build/releases/download/v30.221.20240118.9553d51/emacs-master-x86_64-full.zip
> 
> 
> 9553d51 may reference a savanah commit hash?
> 
> When invoking rectangle-mark-mode, either via M-x or via C-x <SPACE> I get the following error
> message:
> 
> Error: error ("Invalid hash table test" tab-bar--auto-width-hash-test)
>   read(#<buffer  *load*>)
>   load-with-code-conversion
> ("c:/Users/HoechtlJ/AppData/Local/Temp/emacs-int-comp-subr--trampoline-726567696f6e2d626567696e6e696e67_region_beginning_0-hJjV22.el"
> "c:/Users/HoechtlJ/AppData/Local/Temp/emacs-int-comp-subr--trampoline-726567696f6e2d626567696e6e696e67_region_beginning_0-hJjV22.el"
> nil t)
>   command-line-1(("-l"
> "c:/Users/HoechtlJ/AppData/Local/Temp/emacs-int-comp-subr--trampoline-726567696f6e2d626567696e6e696e67_region_beginning_0-hJjV22.el"))
> 
>   command-line()
>   normal-top-level()
> Invalid hash table test: tab-bar--auto-width-hash-test
> 
> Tab-bar-mode is enabled. Do take note that rectangular selections eg. via cua-mode do work.
> 
> I do not know if this is a Windows specific error, a packaging issue or a general bug.

Looks like a duplicate of bug#68668, so I'm merging them.