* bug#72366: srfi-64: on-bad-end-name-function has swapped arguments
@ 2024-07-30 19:51 Tomas Volf
2024-09-30 14:04 ` Taylan Kammer
0 siblings, 1 reply; 3+ messages in thread
From: Tomas Volf @ 2024-07-30 19:51 UTC (permalink / raw)
To: 72366
Hello,
I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
The specification describes the on-bad-end-name-function like this:
(on-bad-end-name-function runner begin-name end-name)
Thus the following should print `x':
(use-modules (srfi srfi-64))
(let ((r (test-runner-null)))
(test-runner-current r)
(test-runner-on-bad-end-name! r
(λ (runner begin-name end-name)
(pk begin-name)))
(test-begin "x")
(test-assert #t)
(test-end "y"))
But it does not:
;;; ("y")
Have a nice day
Tomas Volf
^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#72366: srfi-64: on-bad-end-name-function has swapped arguments
2024-07-30 19:51 bug#72366: srfi-64: on-bad-end-name-function has swapped arguments Tomas Volf
@ 2024-09-30 14:04 ` Taylan Kammer
2024-10-01 23:47 ` Taylan Kammer
0 siblings, 1 reply; 3+ messages in thread
From: Taylan Kammer @ 2024-09-30 14:04 UTC (permalink / raw)
To: Tomas Volf, 72366
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 describes the on-bad-end-name-function like this:
>
> (on-bad-end-name-function runner begin-name end-name)
>
> Thus the following should print `x':
>
> (use-modules (srfi srfi-64))
> (let ((r (test-runner-null)))
> (test-runner-current r)
> (test-runner-on-bad-end-name! r
> (λ (runner begin-name end-name)
> (pk begin-name)))
> (test-begin "x")
> (test-assert #t)
> (test-end "y"))
>
> But it does not:
>
> ;;; ("y")
>
> Have a nice day
> Tomas Volf
>
>
This is clearly a bug IMO and I've now fixed it in my implementation.
I've also decided to remove the check on whether the begin-name is true, because as per spec it's not allowed to be false anyway, and IMO it should call the bad-end-name callback if the begin-name was explicitly passed as #f but the end-name is not also #f.
- Taylan
^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#72366: srfi-64: on-bad-end-name-function has swapped arguments
2024-09-30 14:04 ` Taylan Kammer
@ 2024-10-01 23:47 ` Taylan Kammer
0 siblings, 0 replies; 3+ messages in thread
From: Taylan Kammer @ 2024-10-01 23:47 UTC (permalink / raw)
To: Tomas Volf, 72366
[-- Attachment #1: Type: text/plain, Size: 993 bytes --]
On 30.09.2024 16:04, Taylan Kammer wrote:
> I've also decided to remove the check on whether the begin-name is true, because as per spec it's not allowed to be false anyway, and IMO it should call the bad-end-name callback if the begin-name was explicitly passed as #f but the end-name is not also #f.
>
A little update on this:
Removing that check entirely was stupid, because the value defaults to #f when not provided. So, an explicit #f is allowed by `test-end` as an implementation detail, and is equivalent to not providing a name. Thus, starting a test suite with a name "foo" and ending it with explicit name #f is valid.
However, I've changed the code of `test-end` to check whether the `end-name` was provided rather than whether the `begin-name` was provided. Thus, starting a test suite with an explicit name #f and ending it with a non-#f name WILL raise an error. If `test-end` is provided a name and it is non-#f, then it MUST match the name passed to `test-begin`.
- Taylan
[-- Attachment #2: Type: text/html, Size: 1493 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-10-01 23:47 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-07-30 19:51 bug#72366: srfi-64: on-bad-end-name-function has swapped arguments Tomas Volf
2024-09-30 14:04 ` Taylan Kammer
2024-10-01 23:47 ` Taylan Kammer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).