Implement Meson (take 2)

[Kangie]

This PR picks up after #1097 (thanks @Opaatia) and rebases it on current HEAD.

I was asked to look into completing the port, so I'm not super familiar with c3c - apologies for any obvious oversights / questions!

While some existing CMake logic remains to be ported, there's an opportunity to potentially simplify it. Any guidance on the preferred approach (simplifying vs. following existing logic) would be greatly appreciated.

Progress and remaining tasks:

Done so far:

• remove tilde-backend sources completely including .gitmodules
• generate git_hash.h and conifgure git_hash.h.in (new file)
• set default project arguments c{,pp}_std, warning_level buildtype
• add summary output
• llvm rtti detection
• Wired up CI for Linux (ubuntu-latest), MacOS, msys2, Windows.
• Docs (patches didn't apply cleanly; just focus on meson for now)
• LLVM is again optional
• MacOS support (pending CI testing)
• Windows/msvc support (pending CI testing)

Not implemented:

• Fetching LLVM on Windows
• Mimalloc (would need a submodule, or ideally a Meson WrapDB

Please let me know if there are any changes that I can make while I'm here.

[lerno]

Wrapper uses LLD for the linker as well. I think the wrapper doesn't need to be compiled if compiling without LLVM. However, the possibility to use the internal linker must then be turned off.

[lerno]

I think LLVM optional was for people working on additional backends. Normally, LLVM should be required.

[lerno]

Let me know what else I can help out with.

[Kangie]

Excellent, thank you. I can get that logic in re: LLVM.

Re tilde-backend - I note that a lot of the sources have in-repo been removed, but there's still a .gitmodules referencing the repo that doesn't properly init:

c3c/.gitmodules

Lines 1 to 3 in 70da1f7

	[submodule "tilde-backend"]
	path = tilde-backend
	url = https://github.com/c3lang/tilde-backend

Should I fix the submodule or purge the .gitmodules?

[lerno]

You can drop .gitmodules completely.

[Kangie]

Added some CI that will let me get started on 'Windows' and 'MacOS'. Hopefully it's all straightforward!

Rebased on current dev. Test suite mostly running via meson on Linux, and what isn't running I'll look into - I may have fat-fingered some unit tests while removing boilerplate. Edit: Some things had moved around or been split into multiple tests, no actual failures!

Ok:                 404 
Expected Fail:      0   
Fail:               0   
Unexpected Pass:    0   
Skipped:            0   
Timeout:            0   

Can you enlighten me as to the meaning of the c3 file ext instead of the more common c3t in test/unit_suite/*? - I've eyeballed a few files and can't see any obvious differences.

$ ls test/test_suite/assignment/
alignment_index.c3t  int_assign.c3t  var_variable.c3

[Kangie]

I've squashed down the previous PR into a single commit, and my changes so far down as far as I can at this point.

May need to script up something to generate the list of tests to be 100% sure I got 'em all but we're looking pretty good.

If someone is able to unblock the CI workflow I'll see if I can get Windows and MacOS builds going - Pretty much all of the logic is ported and we're just on to working out what I broke in CI and any edge cases or things I overlooked :)

I think the wrapper doesn't need to be compiled if compiling without LLVM. However, the possibility to use the internal linker must then be turned off.

Do we need to add some preprocessor stuff for that (I don't see any existing toggles) or is the intent that users just don't set --linker=builtin?

[lerno]

There are two sets of tests: one is the unit test variant, the other is what runs by way of a python script.

The python script accepts two types of files (from the ancient times when the compiler was first written): The regular .c3 files which are just compiled normally, doing type checking, and the .c3t files which actually compile things and check the LLVM IR output. They have slightly different directives (in comments) available to them, and because originally things like /* without terminator */ wasn't available, it needed to be in a slightly different format. But actually this is not strictly needed anymore, so when the c3-based external tester is done, these could also be .c3 files. (Although it's been kind of useful to see which ones are supposed to error and which ones are supposed to compile).