Ever-changing randomized translations about c2rust

[glguy]

I think this is related to (possible among other things) relying on the order of items stored in HashMaps in relooper. Can you be more specific about what changes you're seeing?

[danielrh]

Running c2rust twice on https://github.com/danielrh/zstd/tree/c2rust results in 2 different outputs for the same code

here are two runs. No code was changed between the run-- c2rust was simply executed twice on the same code and the results have significant differences-- some types even get different names (eg postfixed with _0) and there are even some indentation differences, probably due to unique wrapping from type name differences, which can make it hard to version control or upstream fixes/updates.

firstrun.zip
secondrun.zip

[danielrh]

it might be desirable to avoid enforcing any line limitations on transpiled code, to avoid difficult merges.
My understanding is that golang's autoformatter doesn't ever wrap lines, partially so that line numbers stay the same before and after running their fmt tool. If users want to wrap the lines of their code, they may wish to use a separate commit hook to do so.

[TheDan64]

If iteration of hash maps are an issue, we could try swapping in https://github.com/bluss/indexmap which is basically an insertion order preserving hash map.

[glguy]

Another aspect of the instability is that we're processing struct/union/typedef declarations in a unstable order which is a function of both the exported pointer value from clang as well as the hashing function in the c_decls hashmap. The "top-level" declarations are exported from clang as a list that preserves the original order. This means that function order is stable.

[glguy]

I think this is fixed for both type declarations and for relooper. We just need to get the commits synced.

[thedataking]

Commits are synced. @danielrh feel free to reopen if this is still an issue.