-
Notifications
You must be signed in to change notification settings - Fork 1k
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
linux fixes recvmmsg flags type for musl/emscripten. #2963
Conversation
r? @JohnTitor (rust-highfive has picked a reviewer for you, use r? to override) |
Changing their types would break existing code, I'd prefer to follow https://github.com/rust-lang/libc/blob/master/CONTRIBUTING.md#breaking-change-policy first. |
a type change to fit Musl and Emscripten. close rust-lang#2945.
d9b37d6
to
00204b0
Compare
Thanks! @bors r+ |
☀️ Test successful - checks-actions, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14 |
This change is causing deprecation warnings downstream, and there's nothing that downstream crates can do about it except to suppress the warning. I don't think the policy laid out in https://github.com/rust-lang/libc/blob/master/CONTRIBUTING.md#breaking-change-policy is appropriate in this case. That policy would make sense if upstream really were changing an API, and especially if upstream were removing it. But in this case musl/emscripten didn't change anything. Instead, libc was simply wrong. I think libc should just go ahead and fix the definition for musl/emscripten. |
Users can prepare the upcoming type changes if they depend on it. |
This change is breaking CI for |
Yes, as I mentioned here, these deprecations don't feel like the right way to handle API changes -- it makes sense to handle removals that way, but it's unclear what downstream users are supposed to do for changes other than We should find an alternative approach though. I'm guessing an 0.3 is considered off the table? |
…itor follow-up on #2963, changing MSG* constant types for musl/emscripten.
I came here from the deprecation warnings spitted out, but I am deeply unclear given the above discussion what the expected alternative going forward is. These constants still seem to exist in glibc, so under what name can we expect them in the future? |
closes #2945