Pass name of crate being compiled to `rustc` when using rust_library/rust_binary

[thoughtpolice]

I found a piece of code I want to use today that uses a macro to generate calls to core::option_env!; the reason is because it is a fault injection library, so the idea is you as a library user invoke the macro to get fault-injectable code, which creates a call to option_env!, which the compiler then runs and embeds the string into the binary.

The macro in question here is CARGO_CRATE_NAME, so the idea is crate "foobar_test" uses failable!() and then if a fault arises, you get a message containing the name foobar_test from everywhere else. If I use Reindeer to generate the build rules for fault-injection or not (it's a very simple library), it doesn't matter; it's my own buck2-only code that uses e.g. rust_library that needs that environment variable passed.

The Cargo reference manual states these are defined as:

• CARGO_PKG_NAME — The name of your package.
  ...
• CARGO_CRATE_NAME — The name of the crate that is currently being compiled. It is the name of the Cargo target with - converted to _, such as the name of the library, binary, example, integration test, or benchmark.

However, the name of the environment variables isn't really relevant. I could change that. I don't see any place something like this is passed through rustc_action.py or anything like that.

Would it be possible to provide rust_library and rust_binary compiled code some alternatives to these variables? Or do they exist already, perhaps? I also wouldn't mind something that told you what the target name of the crate itself was (e.g. root//path/to:rust_binary) either if we can manage it!

[thoughtpolice]

Also, to be clear, I could write a shim for this I guess, and pass it myself via the env field. But it would be pretty annoying for any user of this library to remember to pass that at every call site in the codebase, and it's a pretty specific of a case. So I think it would just be nice and genuinely useful.

[cormacrelf]

@thoughtpolice the upstream library should just use std::module_path! instead. It's a compiler builtin, no environment variables. It returns e.g. mycrate::module::one which is probably more useful for a fault injection library anyway. This is what the tracing crate does.

[cormacrelf]

I just tested println!("{}", module_path!()); in a simple rust_binary target and it prints out the target name.

[stepancheg]

If you are talking about reindeer, you probably need fixups.

[stepancheg]

This is relevant example.

[thoughtpolice]

@thoughtpolice the upstream library should just use std::module_path! instead. It's a compiler builtin, no environment variables. It returns e.g. mycrate::module::one which is probably more useful for a fault injection library anyway. This is what the tracing crate does.

This is a great option, thank you! I wonder if it's worth closing this, though, because while fault-injection is easy to fix, it would be annoying to keep stumbling on this. But adding a layer just for compatibility isn't great, either.

If you are talking about reindeer, you probably need fixups.

No, I already have working Reindeer fixups for my dependency. Like I said, the code using CARGO_CRATE_NAME is code generated by the macro. The macro exists in another crate but that's irrelevant, the use site of the code, and thus the environment variable, is placed inside of the rust_library being compiled. In other words, fault-injection doesn't rely on it being compiled with Cargo, it relies on its client libraries being compiled with Cargo, which isn't the case for us.