rust: Add support for doctest runnables

[bnjjj]

Screenshot:

I would be happy to add tests if you point me to the right place to do it please.

Release Notes:

• Added suuport for doc test in tasks for Rust

[osiewicz]

Thanks for your PR!
Overall it looks good to me, though I've found a few cases where it does not quite work:

1. It does not seem to work unit structs (struct C;).
2. It seems to not work in impl blocks. nvm it does
3. I don't have an example handy, but I don't think it'll work with examples in module-level comments.
4. It seems that if I swap out /// to //!, it does not work either.

[bnjjj]

@osiewicz thanks for your review.

It does not seem to work unit structs (struct C;). ✅
It seems that if I swap out /// to //!, it does not work either. ✅

I don't have an example handy, but I don't think it'll work with examples in module-level comments.

For this one I can't think of a good solution, because we wouldn't have @run tag as it's basically the file itself. I could create another query but I can't find a way to tell treesitter to not match function_item, struct_item and so one. That would conflict with existing ones. Do you have any ideas ?

[osiewicz]

We could try to attach runs to the code blocks and not the annotated items. To be fair I think the bigger hurdle is how to spawn a task for one specific doc test.

[bnjjj]

To be fair I think the bigger hurdle is how to spawn a task for one specific doc test.

Correct me if I'm wrong but with the current implementation it will run one specific doc test because we have the symbol name. Maybe you're talking about your solution (attach the runs to the code blocks).

@osiewicz Could we create an issue as a follow up mentioning that module-level doc tests are not implemented yet ? That's already a good addition I think. What do you think ?

[osiewicz]

Sounds good! Yeah, I was talking about a fully robust implementation and that we'd have to "reverse-engineer" rust doctests a bit to know what query to spawn the tests with. You've nerd-sniped me, I will try to improve it a bit in a follow-up PR. :)
But yeah, this PR stands on it's own. Let's get it in!

[bnjjj]

Talking about the way RA works @osiewicz , is it the plan to use the experimental runnables coming from RA in the future ? I can see a lot of benefits in the way RA works with runnables but I know it might be very specific to Rust so I wanted to know your thoughts on this.

[osiewicz]

We've considered using runnables from RA when we did an initial task implementation - I'm somewhat against it (at least as the only implementation of tests) as other languages don't usually provide similar experience.