cargo test tab completion

[dwijnand]

It would be nice if cargo test <TAB> helped me write out the test I'm looking for.

For example, in the context of using cargo in the cargo project, if I type cargo test ove<TAB> it would be nice if cargo helped me discover the names of the tests in tests/testsuite/overrides.rs that I'm looking for.

[epage]

#6645 is a proposal. for a solution to this problem

[epage]

The other big problem is performance. We have to build and run the binary to discover tests. We could cache them on test runs.

[loynoir]

@epage

I opened #12919 in 2023, because both #5759 in 2018 and #6645 in 2019 are inactive but not small.

cargo completions is a very large proposal.

cargo test --list-test-name is a small proposal.

As small one is subset of the very large one, the small one implement will eventually be part of the very large one implement.

So, I think, it deserve a new feat, as first step.

---

The other big problem is performance. We have to build and run the binary to discover tests. We could cache them on test runs.

Is it possible to let rustc cache meta when build instead of cargo cache meta when test run?

If not, I think should open a rustc proposal in rfc.

[weihanglo]

As small one is subset of the very large one, the small one implement will eventually be part of the very large one implement.

So, I think, it deserve a new feat, as first step.

While small improvements are definitely easier to get done, a CLI option in Cargo once is stabilized hardly get removed. We should take care of avoiding ad-hoc solution for only one command while a general solution might be available.

[epage]

As small one is subset of the very large one, the small one implement will eventually be part of the very large one implement.

To add, this is likely a larger step because of how general it is and how it would interact with the lookup of test names.

As a general feature for querying rest names, we'd need higher accuracy than what completions would need. This would mean compiling and running tests on every invocation, rather than caching.

Is it possible to let rustc cache meta when build instead of cargo cache meta when test run?

We can't gather than information through a compile step. The information is only available by running the tests themselves. I can't think of a way for an RFC to fix this.

[loynoir]

AFAIK, the only way to add test, is test attr after macro expansion.

    #[test]
    fn it_works() {

Is that correct?

If so, can let rustc gather fn name which have test attr, when doing AST.

Not same, but there is CMAKE_EXPORT_COMPILE_COMMANDS to let cmake export compile_commands.json, which generate

type CmakeCompileCommands = Array<{
    directory: `/${string}`,
    command: `/usr/lib/ccache/bin/clang ${string}`,
    file: `/${string}.c`,
    output: `CMakeFiles/${string}.c.o`
}>

Similarly, can adopt this convention to rust like below, or just partially

type RustFunctionName = string

type RustCompileCommands = Array<{
    directory: `/${string}`,
    command: `/path/to/sccache /path/to/rustc ${string}`,
    file: `/${string}.rs`,
    output: string,
    test: RustFunctionName[]
}>

[epage]

There are custom test harnesses, like criterion and libtest-mimic.

Even then, you are expanding the scope even further for a one-off, short-term feature.

[loynoir]

Even then, you are expanding the scope even further for a one-off, short-term feature.

This remind me of something.

When I dive into how napi-rs works, I remember somehow maybe dump some info, using ENV, to generate binding.