Thanks, we definitely want more data to be fetcher from cargoz

Can you provide more details on what rustc/cargo flags it is?

The specific case I'm coming at this with is -Z branch-protection, e.g. -Z branch-protection=pac-ret,bti.
The corresponding cc flag would be -mbranch-protection=pac-ret+bti.
I imagine this would apply to some other flags too and in the end we could just have a rustc => cc flag match statement that could be expanded over time.
We can read the flags through CARGO_ENCODED_RUSTFLAGS and parse those from there.

Thanks that's a good idea, I would accept a PR for it.

Sounds good, will write up a PR then.
Should this be an opt-in thing with its own builder function? E.g. like

cc::Build::new().file("foo.c").inherit_rustc_flags().compile("foo");

Or should we have this done by default with some opt-out?

I think opt-out makes more sense, or maybe we don't even need an opt-out mechanism.

AFAIK the current cargo env usage does not have any opt-out mechanism.

List of codegen options that could be interesting (I'm going through the list of rustc's -C options, and matching them to Clang's options):

• -Car: Deprecated
• -Ccode-model: -mcmodel
• -Ccollapse-macro-debuginfo: Rust specific
• -Ccodegen-units: Rust specific
• -Ccontrol-flow-guard: -mguard
• -Cdebug-assertions: Should probably be controlled by something like CARGO_CFG_DEBUG_ASSERTIONS instead (except that doesn't currently work).
• -Cdebuginfo: Read DEBUG instead (needs to be changed to include all values).
• -Cdefault-linker-libraries: Probably desirable to control this separately between the Rust and C compiler.
• -Cdlltool: ?
• -Cembed-bitcode: -fembed-bitcode
• -Cextra-filename: Rust specific.
• -Cforce-frame-pointers: -fno-omit-frame-pointer
• -Cforce-unwind-tables: ? Maybe some sort of -fexception flag?
• -Cincremental: Rust specific.
• -Cinline-threshold: Deprecated.
• -Cinstrument-coverage: -fprofile-generate?
• -Clink-arg / -Clink-args: Need to ignore, since though we could pass these using the -Xlinker flag, these flags are intended for the final executable, and cc is only producing an intermediary.
• -Clink-dead-code: -dead_strip/--gc-sections
• -Clink-self-contained: May be Rust specific?
• -Clinker / -Clinker-flavor: We could possibly query the linker, and use it if it's a C compiler, but that'd probably be unexpected.
• -Clinker-plugin-lto: ?
• -Cllvm-args: Maybe forward these directly to Clang? Or maybe inside -mllvm?
• -Clto: -flto, though cross-language LTO is hard.
• -Cmetadata: Rust specific.
• -Cno-prepopulate-passes: Rust specific.
• -Cno-redzone: -mred-zone
• -Cno-stack-check: Deprecated.
• -Cno-vectorize-loops: -fno-vectorize
• -Cno-vectorize-slp: -fno-slp-vectorize
• -Copt-level: Read OPT_LEVEL instead.
• -Coverflow-checks: -ftrapv/-fwrapv?
• -Cpanic: -fexceptions
• -Cpasses: ?
• -Cprefer-dynamic: Rust specific.
• -Cprofile-generate: -fprofile-generate
• -Cprofile-use: -fprofile-use
• -Crelocation-model: -mdynamic-no-pic
• -Crelro-level: -Wl,-z,relro?
• -Cremark: -R?
• -Crpath: ?
• -Csave-temps: -save-temps, but might need more to integrate with Cargo?
• -Csoft-float: -msoft-float
• -Csplit-debuginfo: Maybe -gsplit-dwarf?
• -Cstrip: Rust specific (invokes an external tool after compilation).
• -Csymbol-mangling-version: Rust specific.
• -Ctarget-cpu: -march (because -Ctarget-cpu forces that CPU, so -mcpu is too weak (?)).
• -Ctarget-feature: Use CARGO_CFG_TARGET_FEATURE instead.
• -Ctune-cpu: -mtune (or perhaps -mcpu?)