A sealed class with no subtypes cannot be used in declarations in the same file
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
New
|
Undecided
|
Unassigned |
Bug Description
Loading this file:
```
(in-package :cl-user)
(defclass my-class ()
())
(declaim (sb-ext:freeze-type my-class))
;; Either one of these will trigger the bug.
;; (defun my-function ()
;; (the my-class (values (make-instance 'my-class))))
(defun my-function (x)
(declare (my-class x))
x)
```
Results in `Unexpected metatype for #<SB-KERNEL:WRAPPER (ID=1163) for MY-CLASS {50412B03}>`, in `sb-c::
This happens in SBCL 2.1.7, 2.1.9, and SBCL 2.1.9.118-
Output of `uname -a`:
```
Linux prodriguez-2102 5.4.0-89-generic #100~18.04.1-Ubuntu SMP Wed Sep 29 10:59:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
```
Value of `*features*`:
```
(:QUICKLISP :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX
:NON-BASE-
:COMMON-LISP :ELF :IEEE-FLOATING-
:PACKAGE-
:SB-THREAD :SB-UNICODE :SBCL :UNIX)
```
description: | updated |
Sure, it should "work" but as a practical matter sealing a standard-class achieves nothing. Its known placement in the type system will not optimize anything- not method lookup, not TYPEP.
Lest there be any doubt, search for :SEALED in the source code and you'll find that any logic surrounding the lookup of the class state applies only to structure-object and descendants.
Patches to alter that could be considered. Otherwise I'd just as soon have the compiler style-warn upon seeing the declaration, to the effect that the declaration is unsupported for the metatype. (it's nonstandard so there's no spec violation there)