subtypep strongly disagrees with class inheritance

Bug #1886397 reported by Attila Lendvai
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Fix Released
Undecided
Unassigned

Bug Description

something has changed in SBCL in the last few months, maybe a couple of years regarding subtypep and class inheritance.

the symptom:

subtypep now returns (nil t) to something for which it used to return (t t). this breaks the lisp-type -> sql-type mapping in hu.dwim.perec.

with some effort i can probably create a standalone build script that uses only SBCL and quicklisp to reproduce the issue. let me know if the current amount of information is not enough to quickly pinpoint the issue, and i'll try to create that script.

this bug is exhibited by the perec test suite. to load the perec test suite:

(asdf:load-system :hu.dwim.perec.postgresql.test)
(in-package :hu.dwim.perec.test)

and then this transcript happens:

TEST> (lisp-implementation-version)
"2.0.6"
TEST> (subtypep 'CHANGE-CLASS-ASSOCIATION-TEST 'persistent-object)
  0: (SB-KERNEL::%ENSURE-BOTH-CLASSOIDS-VALID #<SB-KERNEL:STANDARD-CLASSOID HU.DWIM.PEREC.TEST::CHANGE-CLASS-ASSOCIATION-TEST> #<SB-KERNEL:STANDARD-CLASSOID HU.DWIM.PEREC:PERSISTENT-OBJECT>)
  0: SB-KERNEL::%ENSURE-BOTH-CLASSOIDS-VALID returned T
NIL
T
TEST> (let ((type1 (sb-c::specifier-type 'CHANGE-CLASS-ASSOCIATION-TEST))
            (type2 (sb-c::specifier-type 'persistent-object)))
        (SB-KERNEL::CLASSOID-SIMPLE-SUBTYPEP-TYPE-METHOD type1 type2))
  0: (SB-KERNEL::%ENSURE-BOTH-CLASSOIDS-VALID #<SB-KERNEL:STANDARD-CLASSOID HU.DWIM.PEREC.TEST::CHANGE-CLASS-ASSOCIATION-TEST> #<SB-KERNEL:STANDARD-CLASSOID HU.DWIM.PEREC:PERSISTENT-OBJECT> T)
  0: SB-KERNEL::%ENSURE-BOTH-CLASSOIDS-VALID returned T
NIL
T
TEST> (sb-c::classoid-subclasses (sb-c::specifier-type 'persistent-object))
#<HASH-TABLE :TEST EQ :HASH-FUNCTION #<FUNCTION SB-KERNEL:TYPE-HASH-VALUE> :COUNT 134 {100480BBA3}>
TEST> (gethash (sb-c::specifier-type 'CHANGE-CLASS-ASSOCIATION-TEST)
               (sb-c::classoid-subclasses (sb-c::specifier-type 'persistent-object)))
NIL
NIL
TEST> (class-direct-superclasses (find-class 'CHANGE-CLASS-ASSOCIATION-TEST))
(#<PERSISTENT-CLASS HU.DWIM.PEREC:PERSISTENT-OBJECT>)
TEST>

we have compared the behavior with an older, working SBCL, and there the classoid-subclasses hashtable has more entries.

the old one that was used as comparison is an ancient version, "1.1.11.53.hu.dwim.3639-da817a7", but i suspect that it broke much more recently than that.

the perec code has non-trivial MOP'ery, which may be relevant. it's possible that it's due to perec doing something illegal. there are metaclasses involved, classes and instances created programmatically, supertypes mixed in automatically, etc.

a wild guess: maybe the recent hash-table changes broke this setup?

Tags: types
description: updated
description: updated
description: updated
Stas Boukarev (stassats)
Changed in sbcl:
status: New → Fix Committed
Revision history for this message
Attila Lendvai (attila-lendvai) wrote :

thank you for the quick fix Stas!

it's working again.

Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.