Maybe make it aggregate the data over all commits and then use that as a learning opportunity to learn about tools like cargo-bench, criterion, cargo-flamegraph and other profiling and benchmarking tools and optimization techniques to see if you can speed it up, reduce its memory usage,…?

Maybe keep maintaining the HashMap you have now and use one of these less portable mechanisms in a test to alert you when you forgot to register one?

Have you tried some tag soup parser? That should work as a last resort even if the ones building a tree structure don’t.

The thing I don’t get in these discussions is that there are people who have convinced themselves that a language we came up with in the first 20 years or so of the industry’s existence is the pinnacle of programming language development and that all those newer languages are really completely equivalent in terms of outcome once you add up their up- and downsides.

That seems based on the same misconception as the whole “fighting the compiler” view on Rust, namely that other languages are better because they let you get away with not thinking through the problems in your code up front. I am not surprised that this view is common in the C world which is pretty far on the end of the spectrum that believes that they are a “sufficiently disciplined programmer” (as opposed to the end of the spectrum that advocates for static checks to avoid human mistakes).

The problem you mention is fundamentally no different from e.g. changing some C internals in the subsystem you know well and that leads to breakage in the code in some other C subsystem you don’t know at all. The only real difference is that in C that code will break silently more likely than not, without some compiler telling you about it. The fact that the bit you know well/don’t know well is the language instead of some domain knowledge about the code is really not that special in practical terms.