Happy branch day! :party:

@notjack: Haven’t gotten to starting the festivities yet. ;)

@stamourv I don’t know if you get this email, but the stxparse tests failed on windows on the release branch https://ci.appveyor.com/project/plt/racket/build/1.0.2619 cc @ryanc

FWIW, fails on master as well: https://ci.appveyor.com/project/plt/racket/build/1.0.2619

@stamourv that link is to the release branch build

you can see the history here; it’s passing on master: https://ci.appveyor.com/project/plt/racket/history

Oh, you’re right. I can’t read appveyor’s page.

I guess I wasn’t expecting it to test back from the tip of the branch?

looks like it failed similarly for the tip of the release branch (see #notifications)

@stamourv, it “fails” under raco test but not when run directly by racket. I suspect a bug in one of the recent rackunit changes, but I won’t really be inclined to spend time debugging it until tomorrow at 8:01am EDT :slightly_smiling_face:

Heh. :)

@notjack: ^

If anyone else wants to investigate, I did narrow it down to the test case in test-litset.rkt labelled "litset, #:at"

@ryanc is it a failure in the sense of a rackunit check failing, or an error of some sort? I recently started using syntax parse in rackunit, maybe there’s a circular dependency somewhere?

this expression in that test looks funky: (check-equal? (syntax->datum (getvar lambda #'(lambda b c))))

did that used to syntax error, which was expected, and now it runtime errors?

@notjack: it’s a misbehavior in that racket test-litset.rkt shows no failure output, but raco test test-litset.rkt prints “1/3 test failures”

@ryanc looking at tcerr, I think that test was never run before

@notjack: ah, good point, I missed that…

old implementation of check-equal? would syntax error when given one argument instead of two, new version makes it a runtime error

and tcerr would catch the syntax error and try to match it against error message patterns, of which there are none for that test

@notjack that seems potentially worrying

@samth I agree. The docs for rackunit never mentioned that checks test their arity during macro expansion though, so it’s at least not a break in documented behavior. But rackunit has a lot of odd undocumented internal behavior.

@notjack since it actually broke something, it seems like maybe that behavior needs to be kept

@samth well, the code in the test case is definitely wrong too, so I don’t think we should hold rackunit to the old behaviour

it’d be cool if we had a versioning system that made it possible to break backwards compatibility

@lexi.lambda don’t get too radical :P

Does the doco really need to explicitly mention checking arity tho? Seems a safe assumption to me unless it says otherwise.

@zenspider checking arity wouldn’t need to be documented. checking arity at compile time using macros probably should be, I’d be really surprised if a library provided “functions” that did that without mentioning it

Thanks @notjack, that explains the rackunit issue; I’ll change the test case. Unfortunately, fixing the test case made me realize literal sets with #:at aren’t working the way I expected, so I’ve got to think harder about that before I commit a fix.

glad to help, and happy to hear the rackunit changes didn’t explode everything