aro translate-c: support for record type translation

[silver-signal]

Edit: Ready for review. See below for a summary of changes.

---

This PR adds support for translating C record types. The PR is still very much a work in progress, so it's probably not worth reviewing now. The only tests that have been added are simple_struct.c and simple_union.c.

Tasks to complete before it's ready:

• [x] Add more tests.
• [x] Cleanup/refactor.

[silver-signal]

This PR ended up being bigger than I thought it'd be, so there are a few features unimplemented. This is my first time working with the aro codebase, so feedback and pointers are welcome. Here's a summary of the changes:

1. fn locStr() fixed to report the correct C source location. In order to facilitate this, I added a source: aro.Source field to Context. It looks like Driver is the correct place to get the Source value rather than Comp, but let me know if this is incorrect.
2. Moved tests related to record types from the old test harness to the new, and added a few new tests. Unfortunately, I wasn't able to test aro with all of the record-related tests because many of them have features (eg. pointers) that aren't supported by aro translate-c.
3. As indicated in my above comment, I made a small change to make the qualifier handling enum for fn canonicalize() a public type. This was done for passing the enum value to the transType() function.
4. Changed the behaviour of prepopulateGlobalNameTable() to add enums and records to the weak_global_names table, and all other names to the global_names table. This matches the behaviour of Clang-based translate-c.

[ehaas]

@f-cozzocrea I notice your last commit says "needs cleanup" - do you want more feedback now, or after the cleanup?

[silver-signal]

@ehaas After the cleanup. After sleeping on it, there's a few things I want to change about the approach before it's ready.

[silver-signal]

@ehaas I pushed some changes, and I feel like the code is in a good place to get feedback. One aspect I'd like feedback about is the alignment of zero-width fields. I have it set to translate zero-width fields to an alignment of 1 right now because that's the behaviour of alignof() in C, but I'm not sure if that's the correct value for translation.

[ehaas]

I think an alignment of 1 for zero-width fields is fine - those fields aren't really usable, they're just to make subsequent fields align differently, so as long as those following fields are aligned I don't see any problems. Perhaps there are more subtle issues at play - @Vexu does that seem ok to you?

[silver-signal]

Thanks for the feedback @ehaas, both of those comments make sense to me.

[silver-signal]

Rebased on master and squashed to 1 commit.

(Sorry for the review request Snektron. Accidentally borked the rebase the first time.)

[silver-signal]

A few more comments and then I think this will be in really good shape! Nice work!

Awesome! Thanks for the feedback to make this a high quality PR. 😄

[ehaas]

@Vexu would you have some time to review this one? With this + if we add array and pointer support, I think we'll be able to translate most decls without clang.

[Vexu]

Absolutely, sorry I forgot about this, I'll get on it in tomorrow.

[silver-signal]

No worries. I figured there'd be a delay because of the 0.12 release. I'm in the middle of moving, so I'll look at your comments and address them in the next week or so.

[andrewrk]

Looks like @Vexu considers this good enough to be merged as-is, so those follow-up improvements can be sent later. Nice work!