Should `cargo-careful` set a `--cfg` flag?

[thomcc]

Should cargo-careful set a --cfg careful in rustflags? IMO yes, so that extra checking can be enabled. Here are some use cases:

1. When building vendored C code in FFI crates, it's hard¹ to know if you should turn on assertions, so I usually don't. If the library has extra levels of stronger/slower assertions, I never turn those on (and generally consider it bad for FFI crates to do so without opt-in from the user).

   However, if I can tell a user is using cargo-careful, I can assume they are willing to pay for extra checking, and so I should turn on all the assertions, even if they're slow and/or verify things which would be redundant with safety provided by e.g. Rust's typesystem or something.

2. Even for pure rust, sometimes I have checks only under #[cfg(test)] rather than debug_assertions. This is usually because they're too costly to consider making a user pay for it for their own debugging (perhaps they increase the time complexity of an algorithm, or whatever). Depending on the case (for example, if safety depends on the correctness I very likely would), I may enable this under cargo-careful as well.

I can think of some other use cases as well, of similar reasoning.

Footnotes

1. Sadly, there's no way to reliably detect if the user has debug_assertions enabled in a build script. Ideally cargo would pass CARGO_CFG_DEBUG_ASSERTIONS to build scripts but because of the way it discovers cfgs, it cannot, and IIUC this is unlikely to change. So the closest you get is checking PROFILE for being "debug" or not, which is... not quite right. (Note that the DEBUG env var is for debuginfo, not assertions). ↩

[RalfJung]

Yeah, similar to how Miri has cfg(miri), something like that would probably also make sense here.