Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Integrate the cty crate into libc's CI #1286

Closed
wants to merge 34 commits into from

Conversation

gnzlbg
Copy link
Contributor

@gnzlbg gnzlbg commented Feb 26, 2019

So this the successor to #1285 (cc @japaric @Amanieu @alexcrichton ).

It imports the cty crate into the libc repository preserving its commit history, and integrates it with libc's CI. That basically amounts to running the same tests that libc runs on the cty crates type for those targets that we support at run-time (type size, alignment, sign, etc. ).

This PR also adds a crate that tests at compile-time that all types between the libc and the cty crates match except for c_void. As @alexcrichton mentioned, c_void matches if both use core::ffi::c_void, and differs otherwise because each crate defines its own in old compiler versions.

WIP: while doing #1285 I noticed that the types differed in some targets because of bugs. I will manually disable the tests in the archs in which they fail (adding the appropriate comments and filling issues), so that we can decide later on a 1:1 case basis if we want to fix them, and how (we can probably fix cty bugs by just bumping the semver major version, but for libc bugs that's a different story). This PR should essentially be a non-functional change for both crates, except that cty now also supports older Rust targets without core::ffi::c_void.

japaric and others added 30 commits May 24, 2017 19:36
Fix mixed signed / unsigned types
change c_{,u}long to match libc v0.2.23 definitions
Copied a few extra definitions from the libc crate.
Include additional types from libc

Copied a few extra definitions from the libc crate.
11: Re-export core::ffi::c_void r=japaric a=jeikabu

japaric/cty#10

Without this trying to use bindgen like:
```rust
let bindings = bindgen::Builder::default()
        .header("wrapper.h")
        .ctypes_prefix("cty")
        .use_core()
        .generate();
```

Results in lots of:
```
error[E0308]: mismatched types
  --> runng/src/protocol/mod.rs:49:43
   |
49 |         let res = nng_setopt(socket, opt, topic_ptr, topic_size);
   |                                           ^^^^^^^^^ expected enum `cty::c_void`, found enum `std::ffi::c_void`
   |
   = note: expected type `*const cty::c_void`
              found type `*const std::ffi::c_void`
```


Co-authored-by: jake <jeikabu@gmail.com>
@rust-highfive
Copy link

@gnzlbg: no appropriate reviewer found, use r? to override

@alexcrichton
Copy link
Member

@gnzlbg it looks like this may be an accident, but it looks like libc depends on cty?

@gnzlbg
Copy link
Contributor Author

gnzlbg commented Feb 27, 2019

Yes that's an accident. I tried to rebase the old branch to remove the commits that added that, but somehow git rebasing does not work across the commit that merged one repository into the other.

I have this on my queue, but haven't had time yet to look at it again.

@alexcrichton
Copy link
Member

Ok just wanted to confirm, no worries! Apart from that looks good to me!

@bors
Copy link
Contributor

bors commented Jul 25, 2020

☔ The latest upstream changes (presumably #1837) made this pull request unmergeable. Please resolve the merge conflicts.

@JohnTitor
Copy link
Member

Closing as the author is inactive, if someone is interested in this change, let us know!

@JohnTitor JohnTitor closed this Jun 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.