Better tests for RECEIVE

phoe commented 2 years ago

Split off from #108

It seems there are some ECL failures on these.

phoe commented 2 years ago

I've tried the macroexpanded version on ECL.

ECL (Embeddable Common-Lisp) 21.2.1 (git:c646799145538997d84ed6d8755be7e7837eb7ef)
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2013 Juan J. Garcia-Ripoll
Copyright (C) 2018 Daniel Kochmanski
Copyright (C) 2021 Daniel Kochmanski and Marius Gerbershagen
ECL is free software, and you are welcome to redistribute it
under certain conditions; see file 'Copyright' for details.
Type :h for Help.  
Top level in: #<process TOP-LEVEL 0x55c5648bbf80>.

> (declaim (optimize safety))
((OPTIMIZE SAFETY))

> (compile nil '(lambda () (MULTIPLE-VALUE-CALL (LAMBDA (ONE TWO) (LIST ONE TWO)) (VALUES 1 2 3))))
;;; OPTIMIZE levels: Safety=3, Space=0, Speed=3, Debug=0
;;;
;;; End of Pass 1.
#<compiled-function 0x55c565112ac0>
NIL
NIL
> (funcall *)
(1 2)

No error is signaled, which is in violation of CLHS 3.5.1.3. The same behavior occurs in code compiled with default safety.

Created a follow-up issue at https://gitlab.com/embeddable-common-lisp/ecl/-/issues/672

ruricolist commented 2 years ago

Thanks for opening the ECL issue.

phoe commented 2 years ago

The issue is now fixed in ECL develop. https://gitlab.com/embeddable-common-lisp/ecl/-/issues/672#note_825682518

How long would it be good to wait before merging this? Should the test be marked as failing on ECL until ECL makes another release?

ruricolist / serapeum

Better tests for RECEIVE #109