Evan Haas

Perhaps this issue should be closed now that aro-based translate-c work is taking place in the main Zig repo?

```c _Complex float x = 1.0f16 + 2i; ```

Should I add this as a test with a `TESTS_SKIPPED`?

I must have tested on an ancient version of clang - looks like `_Complex _Float16` support was added in clang 15, so I just went ahead and added that.

Can you add a test for `getMin` / `getMax`? This PR contains a compile error when using those functions (due to calling `extremeInSubtreeOnDirection` on `self.root` which is a `?*Node`)

Should a missing match get an empty string instead of `data::Value::None`? I could see `None` in the final output being confusing since that could also be a string match.

Happens because the existing typedef we find here: https://github.com/Vexu/arocc/blob/8ab72a4b1a4ff445b39b1f6d23fe2cbe59f37763/src/aro/Parser.zig#L2069 Gets combined with `long` to form a `long long` specifier here: https://github.com/Vexu/arocc/blob/8ab72a4b1a4ff445b39b1f6d23fe2cbe59f37763/src/aro/Parser.zig#L2070 That also led me to suspect other patterns could...

Is the idea that each function that currently recurses on typeof/attributed types, should instead call canonicalize/base on its argument first? I think that would also work and yeah probably simpler.

This branch has a fairly heavy performance hit (~5% for large files), and even with *just* Type.base replacing `canonicalize` where we only want the specifier, it's still about 1.5% slower....

It might be useful to look at the defaults of other package managers for ideas - the cargo source has some good info about retries, including links to other resources:...