-
Notifications
You must be signed in to change notification settings - Fork 13k
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
[regression] ambiguity libc/ffi/os::raw for c_ types #96435
Comments
One reasonable fix is to stabilize these types in (That said, glob vs glob is an acceptable breakage according to the library policy.) |
That would be a fast stabilization, but given that they're rather simple types, that seems potentially reasonable. |
If we were to stabilize, presumably we'd do that on master and back out the PR from beta? I am reluctant to backport a stabilization to fix this (particularly a fast one, as you mention). |
@Mark-Simulacrum Yeah, reverting the PR on beta seems fine for now. |
…rt, r=yaahc Revert "Re-export core::ffi types from std::ffi" This reverts commit 9aed829. Fixes rust-lang#96435 , a regression in crates doing `use std::ffi::*;` and `use std::os::raw::*;`. We can re-add this re-export once the `core::ffi` types are stable, and thus the `std::os::raw` types can become re-exports as well, which will avoid the conflict. (Type aliases to the same type still conflict, but re-exports of the same type don't.)
…rt, r=yaahc Revert "Re-export core::ffi types from std::ffi" This reverts commit 9aed829. Fixes rust-lang#96435 , a regression in crates doing `use std::ffi::*;` and `use std::os::raw::*;`. We can re-add this re-export once the `core::ffi` types are stable, and thus the `std::os::raw` types can become re-exports as well, which will avoid the conflict. (Type aliases to the same type still conflict, but re-exports of the same type don't.)
…rt, r=yaahc Revert "Re-export core::ffi types from std::ffi" This reverts commit 9aed829. Fixes rust-lang#96435 , a regression in crates doing `use std::ffi::*;` and `use std::os::raw::*;`. We can re-add this re-export once the `core::ffi` types are stable, and thus the `std::os::raw` types can become re-exports as well, which will avoid the conflict. (Type aliases to the same type still conflict, but re-exports of the same type don't.)
…rt, r=yaahc Revert "Re-export core::ffi types from std::ffi" This reverts commit 9aed829. Fixes rust-lang#96435 , a regression in crates doing `use std::ffi::*;` and `use std::os::raw::*;`. We can re-add this re-export once the `core::ffi` types are stable, and thus the `std::os::raw` types can become re-exports as well, which will avoid the conflict. (Type aliases to the same type still conflict, but re-exports of the same type don't.)
This reverts commit f5841bb0d2a4f86a2df8fab1124efaa11851c512. Fixes rust-lang/rust#96435 , a regression in crates doing `use std::ffi::*;` and `use std::os::raw::*;`. We can re-add this re-export once the `core::ffi` types are stable, and thus the `std::os::raw` types can become re-exports as well, which will avoid the conflict. (Type aliases to the same type still conflict, but re-exports of the same type don't.)
Revert "Re-export core::ffi types from std::ffi" This reverts commit f5841bb0d2a4f86a2df8fab1124efaa11851c512. Fixes rust-lang/rust#96435 , a regression in crates doing `use std::ffi::*;` and `use std::os::raw::*;`. We can re-add this re-export once the `core::ffi` types are stable, and thus the `std::os::raw` types can become re-exports as well, which will avoid the conflict. (Type aliases to the same type still conflict, but re-exports of the same type don't.)
Introduced by #94503, most likely, cc @joshtriplett
The text was updated successfully, but these errors were encountered: