So? The harness itself does not have a separate Cargo.toml. the post-build.dependencies section gives it the semblance of one.
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.
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.
A file with the same name.
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.
I guess. I'd rather have something like "specify-single-target"
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.
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.
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.