Fix build with macOS system headers

[dtwood]

This allows for builds on macOS, using the assert.h, locale.h, setjmp.h, signal.h, stdarg.h, stdio.h, stdlib.h and string.h system headers. ctype.h, math.h and time.h still do not translate.

It still requires

#define _Nullable
#define _Nonnull
#define __CUDACC__

to be added to the top of any input source file.

[dtwood]

hi,

Unfortunately I didn't actually read CONTRIBUTING.md before writing this commit, so it's already been cleaned with git rebase out of habit.

This is the set of changes that I needed to make to get the following simple "hello world" c program to translate and compile in rust under macOS Sierra 10.12.2

#define _Nullable
#include <stdio.h>

int main() {
    printf("%s\n", "Hello, World!");
    return 0;
}

extern {
    fn printf(arg1 : *const u8, ...) -> i32;
}

fn main() {
    let ret = unsafe { _c_main() };
    ::std::process::exit(ret);
}

#[no_mangle]
pub unsafe extern fn _c_main() -> i32 {
    printf((*b"%s\n\0").as_ptr(),(*b"Hello, World!\0").as_ptr());
    0i32
}

The requirement for

#define _Nullable
#define _Nonnull
#define __CUDACC__

to be added at the top of any input source file, to deal with some annotations in Apple's headers, probably requires a change to language-c to fix. Firstly to define _Nullable and _Nonnull, and then to allow for the version in __attribute__((availability)) to contain more than one dot (10.12 is ok, 10.12.1 is not).

[jameysharp]

Thanks for these patches, and I'm sorry I didn't get to them sooner!

First off, could you check whether you get better results on OS X after commit e903353 from today? Neither Joe nor I were able to test on newest OS X, and his install of 10.11 didn't have the same difficulties.

Second: each of these patches may be a good idea (I want to think about them more) but I don't understand what any of them have to do with being able to compile code translated under OS X.

For example, allowing non camel case names should just suppress a warning, unless you're turning warnings into errors, but either way that isn't Mac specific. Right? I've been globally suppressing these kinds of warnings when I invoke rustc instead, but perhaps this is better; we can certainly discuss it.

Similarly, your improvement to the generated code when casting a block to a different type is probably safe and certainly generates code that looks nicer, but the existing code wasn't actually incorrect, was it?

I just want to make sure I understand what issue each patch in this series is solving, which may involve considering alternative solutions.

BTW, no harm done in using rebase; it looks like it went fine and/or you're a git expert. I'm more concerned about its potential failure modes. I can fix a lot of things after a bad merge, but rebase throws away the data I'd need to fix things if it goes poorly.

Thanks again!

[CallumHoward]

Hi, unfortunately I am still getting the same issue as here after checking out and running cabal install on both e903353 and 7b4f947

[lambdageek]

language-c 0.6 still can't deal with __builtin_fabsf as the list of builtin functions provided by GCC is pretty extensive. visq/language-c#29 is the relevant issue.