Fix build with macOS system headers #110
Conversation
Because of rust's private-in-public rules, an empty enum that's emitted to represent a pointer to an imcomplete type must be public if it's contained in a public struct or argument to a public function.
Before, the c code
```c
int main() {
unsigned a = 0;
if (a) {
return a++;
} else {
return a--;
}
}
```
would translate to
```rust
if a != 0 {
{
let _old = a;
a = a.wrapping_add(1 as (u32));
_old
} as (i32)
}
```
now it translates to
```rust
if a != 0 {
let _old = a;
a = a.wrapping_add(1 as (u32));
_old as (i32)
}
```
These functions are defined as `inline` and non-`static` in the macOS header files, but shouldn't be referenced from any external translation unit, so should be safe it remove if they're not used in this file.
|
hi, Unfortunately I didn't actually read CONTRIBUTING.md before writing this commit, so it's already been cleaned with 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 |
|
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 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! |
|
|
This allows for builds on macOS, using the
assert.h,locale.h,setjmp.h,signal.h,stdarg.h,stdio.h,stdlib.handstring.hsystem headers.ctype.h,math.handtime.hstill do not translate.It still requires
to be added to the top of any input source file.