Initial roadmap

[gnzlbg]

We should come up with a couple of goals for the roadmap of what to do next. The first goal is probably making the crate usable. For that we need to:

• get it running on stable Rust, and
• get rust-lang/rust to use it as is.

To get it running on stable Rust we can just try to stop using unstable Rust features. To get rust-lang/rust to use it, the main blocker was the relationship between #[ignore] and #[test] which was discussed in the internal thread (https://internals.rust-lang.org/t/a-path-forward-towards-re-usable-libtest-functionality-custom-test-frameworks-and-a-stable-bench-macro/9139).

@alexcrichton proposed the following:

I’m not sure I completely follow the trickiness with #[test] and #[ignore] orderings, but it seems to me like we could make both of them procedural macros in the prelude by default perhaps? If both #[test] and #[ignore] were routed to the same procedural macro, it wouldn’t matter which runs first and #[ignore] would just otherwise verify that #[test] exists (removing it).

In the meantime there are also a couple of things that we might want to do, but that's probably better to discuss them in their own issues:

• refactor argument parsing, formatting, json, etc. to make them reusable for other custom test frameworks
• refactor testing and benchmarking into different crates, so that one doesn't need to pull in the whole testing infrastructure for benchmarks and vice-versa
• use the real term crate instead of our own fork
• make sure that libtest is usable as a custom_test_framework (and potentially "libbench" as well if we have splitted them in two)

cc @djrenren

[euclio]

I'd suggest replacing term with the termcolor crate instead. That's what rustc and cargo use. (https://github.com/rust-lang/rust/issues/45728)

[gnzlbg]

@euclio that sounds like a great idea !