Closed spernsteiner closed 10 months ago
How stable are DefIds? I don't mean the printed format itself, but the two indices that comprise a DefId. Do those indices change if the source changes?
Good point - they're not stable at all, so the current approach would behave unpredictably if the def list isn't up to date with the current state of the code. I'll change it to check after parsing that the path part of the DefId
matches what's in the file. Having the file contain DefPath
s or something would make it more robust against source changes, but this approach is much easier to implement and will at least notify the user that a mismatch occurred.
I think an attribute you can put on modules, functions, any item that inner items inherit would be cleaner
That would be easy enough to add. #[c2rust_analyze_test::fixed_signature]
already has a mostly similar effect. My thinking is that for bulk edits such as enabling/disabling an entire module, it's easier to work with a big list of DefId
s than to add/remove attributes on dozens of different items.
Adds an environment variable
C2RUST_ANALYZE_FIXED_DEFS_LIST
, which can be set to a file path containing a list ofDefId
s. Each def on this list will have its pointers markedFIXED
. Rewriting is also skipped for these defs (for now - this might not be strictly necessary).The def list file (if provided) is expected to contain
DefId
s in theirfmt::Debug
format, one per line. That is, each line should look likeDefId(0:6 ~ alias1[0dc4]::alias1_good)
(the short formDefId(0:6)
is also accepted, but is less readable). Blank lines and comments (starting with#
) are ignored. For convenience,c2rust-analyze
now prints all theDefId
s in the crate at startup, so that output can be used to build the def list file.