Simmo Saan

This seems like quite an important thing to have. For UI configuration the README recommends renaming the device, but for YAML configuration there's no way.

Looks like this might be the issue described here: https://github.com/beancount/beangulp/pull/159#issuecomment-2967223714. Beangulp is putting the new entries into `existing_entries` while deduplicating, which causes the new unlabeled transactions to also be used...

The first error also happens on this minimized program: ```c typedef unsigned int uint32_t; typedef unsigned long long int uint64_t; typedef union { struct { uint32_t leaf; uint32_t subleaf; };...

I vaguely recall from looking at it that referencing the inner `leaf` field like that in the initializer is problematic. In particular, CIL has to find the field from somewhere...

If I'm not mistaken, the initializer case is instead handled here: https://github.com/goblint/cil/blob/f5ee39bd344dc74e2a10e407d877e0ddf73c9c6f/src/frontc/cabs2cil.ml#L5524-L5551 There's some Cabs hackery with a special `___matching_field` field name. The code in the initial issue prints these...

Oh, interesting! What's the `while_continue` label for then, if not `continue`? Perhaps it makes sense to rename it or remove it altogether (if it's not needed), because this is just...

Maybe `dune build --verbose` reveals something? There's nothing named `Parser_c` in this repository. Do you happen to have something like that uncommitted in some subdirectory while building this fork?

Well, by flipping the order of recursion in all the list-like rules and also flipping the list cons (`::`) arguments, I think all the lists will be in the reverse...

Technically it would be possible to reverse the list at the right point once everything to be appended has been prepended, but these list reversals might cancel out the parsing...

If we successfully add `vattr`s to parameters and the analysis uses them, then this seems like a CIL printing issue. Are attributes even allowed on function parameters? That might explain...