Add alignment feature and use #[repr(align(x))]

[faern]

Trying to solve #1042.

Here I introduce the discussed feature that will allow going from struct alignment with a private __align field to using #[repr(align(x))]. However, I have not implemented it for all structs that require alignment yet, only in6_addr. This because I did not want to spend too much time before we have discussed and solved the remaining questions regarding this.

One thing to discuss is testing. I have so far not done anything to the CI scripts. So currently they will still test the crate only with the align feature disabled. Thus they will make sure the __align fields are still correct. But no automatic tests make sure everything is correct when the align feature is turned on. What do we want to do about that? Can we insert another cargo test with --features align to make all the Travis jobs run the test suite twice, or will that slow things down too much?

I have tried using this version of libc in rustc and the standard library. And successfully changed Ipv6Addr::new to not use any unsafe and to become a const fn. Whether or not we want that is out of scope for this PR, but my point was that the changes introduced with this PR allow much more flexible usage of the libc structs that have alignment.

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[faern]

Experimented with running an extra iteration of cargo test with the feature activated if the build job is using Rust >=1.25.

[faern]

If you like this approach and find it OK to merge, ping me and I'll add the same things to the remaining __align structs.

[alexcrichton]

Looks good to me! I'd be ok using this for all remaining structs as well

[alexcrichton]

I think some tests may still be failing?

[faern]

Yes. Still some things to solve. I have been busy the last few days, so not entirely sure when I will be done with this. But will ping when I feel I have a finished solution :)

[faern]

Now I got a bit further. But are there maybe nicer ways to write what I have already done?

Also, I struggle with figuring out the test failure on i686-unknown-linux-gnu where the test says bad pthread_cond_t align: rust: 8 (0x8) != c 4 (0x4). The old alignment there is __align: [::c_longlong; 0],, so alignment should be c_longlong which should be 64 bit on all platforms(?), and align(8) works on all other 32 bit platforms.

[alexcrichton]

Ah I think u64 has a 4 byte alignment on 32-bit platforms (or at least on Linux), so that may need a conditional alignment attribute

[faern]

Finally had time to finish the rest of the structs and their corresponding constants. Some open questions:

• Do you think I should document this feature in some way? Either by comment just in Cargo.toml, or a section in the README?
• Is the extra test, no_private_align.rs, an acceptable/reasonable approach to make sure future changes don't accidentally make in6_addr not possible to create instances of without unsafe?
• Is the use pthread_mutex_t; in order to change ::pthread_mutex_t into pthread_mutex_t acceptable? I did not find a way to make the macro accept anything other than an ident for the $t2 argument.

[alexcrichton]

Thanks! All the changes look good to me yeah, although I'd be fine without the no_private_align.rs tests as well, we have no more reason to add fields that don't exist!

For the feature, yeah, mind adding a blurb to the README about it?

[faern]

Done. I removed the commit that added the custom test and added a commit with an extra paragraph in the README.

[alexcrichton]

@bors: r+

Thanks!

[bors]

📌 Commit e167a73 has been approved by alexcrichton

[bors]

⌛ Testing commit e167a73 with merge 8565755...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 8565755 to master...