Skip to content
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

Closed
Mark-Simulacrum opened this issue Apr 26, 2022 · 4 comments · Fixed by #96492
Closed

[regression] ambiguity libc/ffi/os::raw for c_ types #96435

Mark-Simulacrum opened this issue Apr 26, 2022 · 4 comments · Fixed by #96492
Labels
regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Milestone

Comments

@Mark-Simulacrum Mark-Simulacrum added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Apr 26, 2022
@Mark-Simulacrum Mark-Simulacrum added this to the 1.61.0 milestone Apr 26, 2022
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Apr 26, 2022
@petrochenkov
Copy link
Contributor

petrochenkov commented Apr 26, 2022

One reasonable fix is to stabilize these types in std::ffi.
That will allow using use reexports instead of type aliases, which will remove the ambiguities.
They are the same types as stable types in std::os::raw just exposed from a different (but also stable) location in the same crate.

(That said, glob vs glob is an acceptable breakage according to the library policy.)

@joshtriplett
Copy link
Member

That would be a fast stabilization, but given that they're rather simple types, that seems potentially reasonable.

@joshtriplett joshtriplett added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Apr 26, 2022
@Mark-Simulacrum
Copy link
Member Author

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).

@Dylan-DPC Dylan-DPC removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Apr 26, 2022
@joshtriplett
Copy link
Member

@Mark-Simulacrum Yeah, reverting the PR on beta seems fine for now.

Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Apr 29, 2022
…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.)
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Apr 29, 2022
…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.)
@bors bors closed this as completed in 07ea143 Apr 29, 2022
ehuss pushed a commit to ehuss/rust that referenced this issue May 4, 2022
…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.)
MabezDev pushed a commit to esp-rs/rust that referenced this issue May 17, 2022
…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.)
workingjubilee pushed a commit to tcdi/postgrestd that referenced this issue Sep 15, 2022
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.)
workingjubilee pushed a commit to tcdi/postgrestd that referenced this issue Sep 15, 2022
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.)
@dtolnay dtolnay removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Sep 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants