Skip to content

Guard cfg'd fields in generated C++ operator== and operator!= - #1192

Open
Don-Yin wants to merge 2 commits into
mozilla:mainfrom
Don-Yin:fix-937-cfg-field-eq
Open

Don-Yin wants to merge 2 commits into
mozilla:mainfrom
Don-Yin:fix-937-cfg-field-eq

Conversation

@Don-Yin

@Don-Yin Don-Yin commented Oct 26, 2026

Copy link
Copy Markdown

Fixes #937.

With a field behind #[cfg(feature = "...")], the generated C++ operator== / operator!= still compared that field unconditionally, so the header failed to compile whenever the feature's define was off (use of undeclared identifier 'alloc_size'). The struct itself already wraps the field in #if, but the comparison didn't.

For == and !=, when any field has a cfg, I now emit each comparison inside its own #if block and end the expression with a neutral true/false, so it stays valid whichever fields are present. Structs without cfg'd fields produce the same output as before.

generated header with the old and new binary, compiled with the feature off and on

I dropped the FIXME(#634) derive-eq/neq opt-out on the existing ConditionalField test so it covers this, and updated the expectation. cargo test, fmt and clippy pass locally.

Fixes mozilla#937

Signed-off-by: Don Yin <Don_Yin@outlook.com>
Signed-off-by: Don Yin <Don_Yin@outlook.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

derive-{eq,neq} doesn't account for #[cfg()]d fields.

1 participant