Fix #98: Add support for 16-bit floating point numbers

[jcmartin]

This adds support for the following 16-bit floating point numbers:

• Support for half-precision floating point __fp16, _Float16, and _Float16x.
• Support for bfloat16 __bf16.

This change does not cause any breaking changes and so the minor version was bumped.

[jcmartin]

@Bodigrim I understand that you are doing maintenance for this package at this point. Would you accept a pull request to fix this issue? This is largely affecting the newest distributions of macOS that modified math.h to be dependent on __fp16, which makes it something of a high priority in order for c2hs to continue to work on that platform.

[Bodigrim]

This change does not cause any breaking changes and so the minor version was bumped.

Adding new constructors to exported data types is a breaking change unfortunately. Not a big deal, just bump the major version please.

---

@jcmartin I am more of caretaker than maintainer, I don't really have any proper domain knowledge. If someone is capable to review, I'll be happy to merge and release.

@vmchale given your comment in #98, might you be interested to take a look?

[jcmartin]

@Bodigrim Fair enough. If it is alright, do you mind if we do two pull requests? One that does not have bfloat16 and one that adds it as well. This way people can benefit from the __fp16 change without having to wait for c2hs to update its dependencies?

This only works if both 0.9.5 and 0.10.0 will be published though.

[Bodigrim]

To be frank, I don't have that much bandwidth. It's easier to revise the latest release of c2hs than make an additional release of language-c.

[jcmartin]

I have bumped the version to 0.10.0.

[elwright777]

I tested jcmartin's patch, building a version of c2hs with his language-c-0.9.5. It successfully parsed the math.h header from Apple's Xcode 16.1, which had failed before the patch. (I also noted this as a comment in #93.)

[Bodigrim]

I'm trying to get cabal test to pass before cutting a release. Apparently baselines are off, probably have been broken for a long time. Any help with it will be appreciated and will speed up language-c-0.10 release.

[jcmartin]

@Bodigrim I will try to take a look at this in the next few days. My initial take on macOS was that some of the tests were failing because the compiler messages appear different depending if they arise from a macro or not. Fixing this the correct way would be rather annoying as it would require tracking when the compiler changed the messages and performing a different test depending on the compiler. It may also be the case that the version that Apple ships has a different output than what is available via your favorite package manager.

I have not run cabal test under linux yet.

[Bodigrim]

I have not looked at the testing framework, maybe we can sanitize / filter certain lines to achieve uniform behavior?

I'm also on macOS, one way to run cabal test under Linux would be to set up a CI job.

I'd like to have an evidence that tests pass at least for one platform. If it happens to be easier to achieve for Linux / GCC instead of macOS / clang, that's fine.

[jcmartin]

I ran these cabal test under linux with gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0. Everything is passing.

[Bodigrim]

Awesome, published: https://hackage.haskell.org/package/language-c-0.10.0