bug#72370: srfi-64: test-apply requires at least one specifier

[Taylan Kammer]

On 30.09.2024 20:50, Taylan Kammer wrote:
> On 30.07.2024 21:51, Tomas Volf wrote:
>> Hello,
>>
>> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>>
>> The specification says the following regarding the test-apply:
>>
>>> If one or more specifiers are listed then only tests matching the specifiers
>>> are executed.
>> That implies that specifiers are optional and the following code should work:
>>
>>     (use-modules (srfi srfi-64))
>>     (test-apply (λ () #t))
>>
>> However it does not:
>>
>>     Backtrace:
>>     In ice-9/boot-9.scm:
>>       1752:10  8 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
>>     In unknown file:
>>                7 (apply-smob/0 #<thunk 7fdf6ecc4300>)
>>     In ice-9/boot-9.scm:
>>         724:2  6 (call-with-prompt _ _ #<procedure default-prompt-handler (k 
>> proc)>)
>>     In ice-9/eval.scm:
>>         619:8  5 (_ #(#(#<directory (guile-user) 7fdf6ecc7c80>)))
>>     In ice-9/boot-9.scm:
>>        2836:4  4 (save-module-excursion _)
>>       4388:12  3 (_)
>>     In srfi/srfi-64/testing.scm:
>>        947:34  2 (test-apply #<procedure 7fdf63956108 at 
>> /home/wolf/src/guile-wolfsden/tests/s…>)
>>        938:47  1 (test-apply #<procedure 7fdf63956108 at 
>> /home/wolf/src/guile-wolfsden/test…> . _)
>>     In unknown file:
>>                0 (reverse #t)
>>
>>     ERROR: In procedure reverse:
>>     In procedure reverse: Wrong type argument in position 1: #t
>>
>> Have a nice day
>> Tomas Volf
> If anyone's wondering why I don't want to work with the upstream SRFI-64 
> code, reading the implementation of test-apply is all you need. :-)
>
> It almost makes me think it must be machine-generated code, or intentionally 
> obfuscated. But anyway.
>
> My implementation actually had a similar bug, but it should be fixed now with 
> this commit:
>
>     
> https://codeberg.org/taylan/scheme-srfis/commit/3091e3b863d53a012b4be4376814bb67bf09020d
>
> I've also noticed the other issue with test-apply that you reported as a 
> separate bug report, and will fix that later.
>
> Thanks a ton for all these reports, because it seems you've really caught a 
> ton of edge-cases, and some glaring issues in seldom-used parts of the API.
>
> - Taylan
>
By the way, I just noticed another issue with test-apply:

It will sometimes call the supplied test runner's on-final handler, and 
sometimes not.

I had made sure to imitate the behavior one-to-one in my own SRFI-64 
implementation, but looking at the code one more time and pondering on the 
behavior a bit, this seems rather arbitrary and most likely not intended.

So, I've changed it in my implementation so that the on-final handler will 
always be called at the end when using test-apply. Fix is implemented with this 
commit:

    
https://codeberg.org/taylan/scheme-srfis/commit/a33b9f0cd4558d255605eccfa1a59111b8eb3716

- Taylan