Don't apply name_to_crate_name to test binary names.

[martinboehme]

Normal rust_binary targets don't do this, so for consistency, don't do it in tests either.

An additional motivation for this change is that I'm trying to whittle down the number of uses of the name_to_crate_name function, as it doesn't take a possible crate_name attribute into account. For context, see also the changes and discussion in

#645

[martinboehme]

@illicitonion I see now that you specifically introduced the hyphen-to-underscore conversion in #528. I'm not quite clear on why it was required at the time though... can you explain?

[martinboehme]

@illicitonion At any rate, I've run bazel test @examples//hello_lib/..., and everything passes (including the hello-lib-test that you renamed to contain dashes in the name in #528), so whatever the original problem was, it appears it's fixed now?

[illicitonion]

Hmm...

On the one hand, some other change must have compensated for the change I added for the failing test, because the tests are passing.

On the other hand, cargo does do this replacement for test binaries (notice the "Running" line):

% cargo init test-with-hyphens
     Created binary (application) package
% cd test-with-hyphens
% cargo test
   Compiling test-with-hyphens v0.1.0 (/Users/dwh/tmp/test-with-hyphens)
    Finished test [unoptimized + debuginfo] target(s) in 0.72s
     Running target/debug/deps/test_with_hyphens-17b0d88f95f3c1f4

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

But "how cargo happens to name intermediate outputs" isn't super important, people shouldn't be relying on it (and if they are, we should add tests covering the contract we offer).

I guess we'll find out if something fails, and can always switch back if we need... WDYT?

[martinboehme]

Hmm...

On the one hand, some other change must have compensated for the change I added for the failing test, because the tests are passing.

On the other hand, cargo does do this replacement for test binaries (notice the "Running" line):

% cargo init test-with-hyphens
     Created binary (application) package
% cd test-with-hyphens
% cargo test
   Compiling test-with-hyphens v0.1.0 (/Users/dwh/tmp/test-with-hyphens)
    Finished test [unoptimized + debuginfo] target(s) in 0.72s
     Running target/debug/deps/test_with_hyphens-17b0d88f95f3c1f4

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Interesting...

But "how cargo happens to name intermediate outputs" isn't super important, people shouldn't be relying on it (and if they are, we should add tests covering the contract we offer).

I guess we'll find out if something fails, and can always switch back if we need... WDYT?

I think there are two competing concerns here: a) What does Cargo do, and b) What would Bazel typically do?

Bazel would typically name the output files for the Bazel target name, and we already do this for rust_binary rules, and I think it makes more sense to be consistent with Bazel's conventions rather than Cargo's conventions because we are, after all, executing a Bazel build rule.

So if you're happy with this, I'm happy to try it out. I don't want to force this on you though -- nothing I'm doing actually needs this change, I just noticed in the course of making other changes and thought it would be nice to make rust_test more consistent with rust_binary here. And so I would have not problem reverting this change if it turns out to be a problem.

All of this is a long-winded way of saying: If you're happy with this, please merge (I don't have write access). If you'd rather hold off on this, I'm fine with that too.