Improve C decl map handling of #ifdefs and multiple declarations
#1566
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
one transformation step used a non-order-preserving HashMap by mistake
we don't need to check this assertion again after only increasing the larger side of its comparison
this will serve as the anchor from which to search backwards for indications that we should cut short the prefix of the source range associated with this decl
fw-immunant
force-pushed
the
fw/c-decls-ifdefs
branch
4 times, most recently
from
dd334fc to
097a37d
Compare
fw-immunant
changed the title
#ifdefs#ifdefs and multiple declarations
fw-immunant
force-pushed
the
fw/c-decls-ifdefs
branch
from
ed06cd8 to
f5c6054
Compare
kkysen
reviewed
Jan 26, 2026
kkysen
reviewed
Jan 26, 2026
note, this is not all preprocessor directives but only those likely to separate this declaration from disabled code this allows us to emit more precise source ranges when transpiling files in different ifdef configurations
maybe this additional organization makes things clearer
our Rust is not new enough for the latter
in the case of top-level multiple declarations like `int a, b;`, these declarations share the same begin loc. in this case we want to process a before b, so break ties with their end loc
this is not necessarily the case for multiple declarations like `int a, b;`, where `earliest_begin_loc` takes on the end of the first declaration. it may be the case that we should instead enforce this invariant by moving `earliest_begin_loc` backwards instead of moving `begin_loc` forwards, depending on what best suits c2rust-postprocess
fw-immunant
force-pushed
the
fw/c-decls-ifdefs
branch
from
f5c6054 to
8a6970f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When we integrate with Hayroll, we'll want to merge C decl maps from different runs of the transpiler in which different, overlapping subsets of code are enabled via the preprocessor. In prototyping this I ran into cases where we attribute all preprocessor-disabled code immediately preceding a function to that function's source range.
This PR adds logic to our decl map generation to avoid this misattribution.
While we're at it, fix a bug causing reordering of C decls in
c_decls.jsonfiles: the decl map should always match the order in the C source.This also improves handling of multiple declarations (e.g.
int a, b;), which libmcs makes particular use of.