Use llvm-hs to generate LLVM code

[ollef]

Instead of doing it with strings.

https://github.com/llvm-hs/llvm-hs

Also a good idea to clean up the code generator.

[ollef]

About cleanups: There's some annoying code that tracks what needs to be forward declared in the generated code because duplicate forward declarations aren't allowed. With llvm-hs we have an AST for the generated code, so perhaps forward declarations could be extracted from usage.

[ollef]

The code-generator could also probably use the VIX type or some transformer on top of that for simplicity.

[typesanitizer]

The strings don't work out of the box on Ubuntu (I'm guessing you are on macOS?) as the default binaries generated are differently named (llvm-link-4.0 and llc-4.0 instead of llvm-link and llc). So +1 to replacing strings. Just out of curiosity, is there any specific LLVM version requirement?

[ollef]

Thanks for that info @theindigamer. Perhaps that could be fixed before going to llvm-hs which is a bigger change, though I'm planning on working on it pretty soon. Do you know if there's a way to discover the right binary names for these tools on Ubuntu? If there is, it might only require some minor changes to this file. If you'd like to contribute, that sounds like an excellent first task, and would be very welcome! :)

I think Sixten should be compatible with both LLVM 4 and 5 but haven't done any work to find out the exact bounds, and we're not yet doing any testing to ensure compatibility. I do most of my development on Arch Linux which now has LLVM 5, though the update was fairly recent. I also occasionally try it on a Mac. I'd like to do more CI to ensure compatibility.

[typesanitizer]

I don't know a generic way to get it working across all Linux distros, although I did install LLVM 5 and associated packages (on Ubuntu) and checked that the binaries follow the same naming scheme, i.e. clang-5.0, llvm-link-5.0 and llc-5.0. So this naming schemes seems to hold for 3.8, 4.0 and 5.0. Of course, a silly stop-gap solution is to just check for failure and try out different commands (still hard coded) if needed. We could double-check what the binary names are for RPM-based distros and put those in too. But yeah, this doesn't sound like a nice solution...

A more convoluted slapdash solution would be to use the output of compgen -c (works in bash/zsh, unsure about other shells) like so

 $(compgen -c | grep -xE "clang(-([456]).0)?" | sort --reverse | head -n 1) fname.c

which will just use the latest version (if numbered) or simply clang. There's the obvious shortcoming of portability (fix: replace shell with Haskell), not to mention that it might accidentally use mismatched versions of LLVM/Clang, which will go unnoticed.

I think the key question here is: how long do you think the porting will take? If it's going to take long, then it might be a good idea to think this through further and come up with a reasonable solution. If not, then maybe just leave this as is for now and directly jump to llvm-hs once it is ready.

I was actually going to work on the test writing issue, when I noticed this problem. For now, I've just changed the strings locally and will keep the changed strings uncommitted and only commit the test once it's done.

[ollef]

Using llvm-hs is next on my list, so hopefully the wait won't be too long. Since you're happy with a few local changes I guess we can just wait until someone else complains. :)

Nice! That will be very welcome!