Past, present, and future for Rust testing

[Manishearth]

I’m proposing that the harness dependencies are merged with the crate-under-test dev-dependencies?

So? The harness itself does not have a separate Cargo.toml. the post-build.dependencies section gives it the semblance of one.

But that’s always the intention of a context?

no_main has a subtler implication, “compile this as a binary crate but do not include a main”. If you just omit main and plan to link it in rustc will not compile it; you have to either specify main or specify no_main, you cannot compile binary crates otherwise.

How about just “build contexts”?

This is better. But again, I feel that focusing on the fact that test does do a normal build is irrelevant, because that’s an implementation details, not how we want things to be modelled by people.

How could the two folders have the same file?

A file with the same name.

So that you can, for example, split your test files into multiple directories for organizational purposes

Hmm. I’d rather make subfolders work but I guess this is the path of least resistance for that. I’ll re add when I get back.

So we’re changing from apply-to-lib to something like never_exits?

I guess. I’d rather have something like “specify-single-target”

[jonhoo]

So? The harness itself does not have a separate Cargo.toml. the post-build.dependencies section gives it the semblance of one.

Yeah, my proposal is essentially to re-use the dependencies of the build context crate as the harness dependencies. It does mean that you end up pulling in slightly too many (larlpop_util in @fitzgen’s example) when compiling the build context, but meh. That said, I’m also fine with a dedicated new section as in the current eRFC and @fitzgen’s post above.

If you just omit main and plan to link it in rustc will not compile it; you have to either specify main or specify no_main, you cannot compile binary crates otherwise.

Ah, missed this. Yeah, I guess the build context crate has to include that as a field then. Either in Cargo.toml (which means either all the build contexts in a crate has it, or none do), or in the build_context annotation directly.

A file with the same name.

I still don’t see how this presents any problem?

I’d rather have something like “specify-single-target”

Seems fine.

[Manishearth]

I still don’t see how this presents any problem?

You can’t ask it to run one of them.

That said, you can already cause clashes by explicitly defining targets and clashing with files under tests/ so that’s probably ok. Like I said, I’m going to re add this (but am out of town till Monday)

Going to leave the no_main thing as an unresolved question because I really don’t like adding codegen options to Cargo.toml. I also feel like it’s just one example out of many other possible ones so just providing the ability to toggle no_main is a band aid.

[Manishearth]

Posted at https://github.com/rust-lang/rfcs/pull/2318

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.