Add support for using ~matches with multiple values in a check test

[ashton314]

Previously something like this wouldn't work:

check: values(1, [2, 3, 4])
       ~matches values(a, [b, c, d])

Now it does!

I'd be happy to add unit tests—I need someone to show me where they're at if there are any. Thanks!

[mflatt]

Tests are in rhombus/tests directory. There's no file or specific unit tests for the check form right now, though, so adding rhombus/tests/check.rhm would make sense.

[ashton314]

Huh… this is a little tricky to test because the thing I'm testing is check itself. I'm having difficulty testing that a test fails in the way I want it to. For example, this isn't working:

check:
  ~eval
  check: values(1, [2, 3])
         ~matches a
  ~raises "matching a"

Can you think of a way I can test failure?

[mflatt]

I think you will need to set Print.current_error to capture error output, but you'll also need to import from lib("racket/base.rkt") for now to be able to create a string port and extract the string.

My guess is that you'll need ~eval only if you write syntax-error tests.

[ashton314]

Ok; I'll give that a whirl

[ashton314]

Capturing the output and testing its contents led me down a yak shave that resulted in me adding Port.open_output_string, Port.get_output_string, and String.contains. I've added tests for the last one; I'm not sure if tests for the Port.* functions are necessary, as they seem to be little more than aliases to the Racket implementations.

I'm a little worried that this PR got away from me and there's a simpler solution here. Please let me know if that's the case.

[usaoc]

Not trying to discourage you, but I think ~matches already supports multiple values by supplying multiple groups, like

#lang rhombus/static
check:
  values(1, 2, 3)
  ~matches: 1; 2; 3

[mflatt]

I completely forgot that ~matches supports multiple patterns that way. Adding values still seems like a good idea, since it seems like a more expected and discoverable form.

[usaoc]

I think it would be better if you avoided adding in new functions for now; you could import what you need in the test file and leave a note there. Actually, adding tests isn’t urgent at all, so don’t feel obliged to do it.

I have another question though: should we remove the multi-group form? It’s probably better if we just keep the single-group form. I don’t see the multi-group form used anywhere, either.

[mflatt]

Removing the multi-group ~matches form is ok with me.

[mflatt]

I agree that it would be fine to import the needed Racket functions just into the test code, but I also think it's ok to add them to Rhombus. These seem like things that will definitely be needed eventually, even if we decide to adjust names eventually.

[usaoc]

I think it’ll be good if we can at least merge the main part of this PR (the change to check). If you’re okay with that, I can cherry-pick that commit and merge it; other commits look more tangential, and deserve their own PRs.

[ashton314]

Finals done did me in. 😅 That's all over now so I can revisit this. I'm fine if you want to go ahead and just merge it though.

[usaoc]

No worries, it’s okay if you’d like to further improve it! I just think that putting too many things in one PR makes it more difficult to go through.

[usaoc]

I cleaned up and refined this PR’s commits at usaoc/rhombus-prototype@ce73a2f (and shamelessly added myself as the coauthor). If you don’t mind, this PR can reset to that commit and I’ll merge them.