Bump version to 0.2.141

[atezet]

Bump version as requested in rust-lang/socket2#405

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[JohnTitor]

Let me merge some more PRs in the review queue.

[jbg]

FYI, upwards of 48,500 crates currently fail to build on all musl targets because libc 0.2.140 is broken on musl. IMHO, it may be worth considering yanking 0.2.140 and/or publishing a quick 0.2.141 even without the extra merged PRs.

[atezet]

Maybe I failed to express the urgency of this PR. I figured it'd be merged and released pretty quickly (and I didn't have the numbers handy). Thanks @jbg!

@JohnTitor It would be great if we could get the release out ASAP

[JohnTitor]

FYI, upwards of 48,500 crates currently fail to build on all musl targets because libc 0.2.140 is broken on musl. IMHO, it may be worth considering yanking 0.2.140 and/or publishing a quick 0.2.141 even without the extra merged PRs.

@jbg Seems you misunderstand how this crate works, it just exposes consts/fns/structs etc. We've also tested the build for musl on CI and it's green. If you refer to the socket2 issue, its build is broken because it uses an undeclared item on this crate, note that it's not this crate's fault.

But yeah, let's make a new release now then, @bors r+

[bors]

📌 Commit d58ff69 has been approved by JohnTitor

It is now in the queue for this repository.

[bors]

⌛ Testing commit d58ff69 with merge 26744a7...

[JohnTitor]

It's interesting that you don't have even a single word of appreciation for my maintaining this crate and making releases, whereas you immediately downvote me for asking you to wait a bit to take care of the PR waiting for review. Sigh.

[jbg]

FYI, upwards of 48,500 crates currently fail to build on all musl targets because libc 0.2.140 is broken on musl. IMHO, it may be worth considering yanking 0.2.140 and/or publishing a quick 0.2.141 even without the extra merged PRs.

@jbg Seems you misunderstand how this crate works, it just exposes consts/fns/structs etc. We've also tested the build for musl on CI and it's green. If you refer to the socket2 issue, its build is broken because it uses an undeclared item on this crate, note that it's not this crate's fault.

But yeah, let's make a new release now then, @bors r+

Thanks very much for the release, and apologies for the misunderstanding, I mistakently thought a libc patch release had made those constants conditional on glibc targets and broken socket2, rather than a socket2 patch release starting to depend on libc constants that were unexpectedly only exported on glibc targets.

Is there a way the docs could show when constants are target-specific? The 0.2.140 docs don't indicate in any way that DCCP_* is only exported for glibc targets in that version. Maybe rustdoc doesn't provide a convenient way to do that?

[JohnTitor]

Yeah, given how we (re)export items, IIUC it's difficult to show items on docs.rs per target.
But we have platform-specific docs on gh-pages (it's linked on README): https://rust-lang.github.io/libc/#platform-specific-documentation
Does it work for you?

[jbg]

Yes, these are excellent.

I think despite the link from README they might be easily missed, though, given how docs.rs is in many people's muscle memory.

I wonder if it's possible somehow to get rustdoc to produce the little yellow tags (like the Unix and Windows ones on https://docs.rs/tokio/latest/tokio/signal/index.html) for target-specific re-exports. I think somehow adding a #[doc(cfg)] attribute to the re-exports would do it, but that would require the docs to be built with nightly rustdoc (which docs.rs does use).

[JohnTitor]

#[doc(cfg(...))] might be a good solution here, although it should be quite hard as this crate supports a lot of targets...

[jbg]

I'll have a play and if it's not too ugly I'll submit a PR for consideration :)

[bors]

☀️ Test successful - checks-actions, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14
Approved by: JohnTitor
Pushing 26744a7 to master...

[Thomasdezeeuw]

Thanks @JohnTitor!

[JohnTitor]

Published on crates.io: https://crates.io/crates/libc/0.2.141

[atezet]

Thanks a lot @JohnTitor