Check that more targets build

[gnzlbg]

No description provided.

[rust-highfive]

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

[bors]

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

[gnzlbg]

cc @humenda I had to fix a couple of bugs in the l4re implementation related to the --features=extra_traits. Now it should build there too, but the l4re types won't implement the classical traits for now (you can just grep for allow(missing_debug_implementations) to find all the issues there).

cc @Susurrus it seems that the extra_traits feature impacted uclibc as well. I don't know if the current CI covers all issues (probably not since there are some targets like arm / aarch64 that are not tested on CI with uclib), but now it should be possible to implement these while still being sure that libc compiles on more targets.

[gnzlbg]

@bors: r+

[bors]

📌 Commit 183c51b has been approved by gnzlbg

[bors]

⌛ Testing commit 183c51b with merge 83d97c2...

[bors]

☀️ Test successful - checks-cirrus, checks-travis, status-appveyor
Approved by: gnzlbg
Pushing 83d97c2 to master...

[humenda]

cc @humenda I had to fix a couple of bugs in the l4re implementation related to the `--features=extra_traits`. Now it should build there too, but the `l4re` types won't implement the classical traits for now

AFAIU, it's only `pthread_addr_t`. I've moved the definition into other.rs and added the definition in l4re.rs to the `s!` macro. Is there anything special I need to care about when deriving `Debug`?

[gnzlbg]

Is there anything special I
need to care about when deriving Debug?

As long as the struct is not repr(packed), then no. The only reason Debug cannot be auto-derived is because it contains an array with more than 32 elements, or a type that does not implement debug. Almost all other manual debug implementations show how to handle larger arrays, so be sure to check a couple of those.