-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Trait re-exports fail due to privacy of containing module #18241
Comments
I've noticed this too while compiling nphysics, I've narrowed it to http://is.gd/X0EHDP The error is
I'm using |
I'm facing the same problem for quite some time now (currently rustc 1.0.0-nightly (29bd9a0 2015-01-20 23:03:09 +0000)). Is this a bug or is it intended behavior? |
@nikomatsakis is this expected? |
Just ran into this bug in my code, would love to see a fix for this! |
Im also still running into this from time to time (rustc 1.3.0). I'd love to see it fixed or clarified whether this is intended or a bug. |
I also have this with rustc nightly (from PPA: "201510280406 |
@steveklabnik I think this is a bug, actually. @nrc @alexcrichton do you agree? |
@steveklabnik yes I realize I'm responding to a comment from Jan 28 :) a bit late, I know |
@nikomatsakis this was "fixed" by #28504 but reverted by #29325 due to a regression. Personally, I think that the correct fix for the regression should be to make |
@nikomatsakis better late than never ❤️ |
@nikomatsakis yeah this looks like a bug to me, and I think @eljay is right in that #28504 is probably the right fix if we deal with |
This can be simplified even further to: http://is.gd/QG9LGU. Also an additional note, this only affects usage in the same crate. Other crates are able to use the re-exports fine. |
Still a bug in 1.6 😢 |
+1 |
still a bug in cargo 0.8.0-nightly (28a0cbb 2016-01-17) |
For those who may fall on this issue, it can be bypassed by using the UFCS syntax: For example http://is.gd/QG9LGU becomes http://is.gd/zYo5Qm |
…tsakis This PR allows using methods from traits that are visible but are defined in an inaccessible module (fixes #18241). For example, ```rust mod foo { pub use foo::bar::Tr; mod bar { // This module is inaccessible from `g` pub trait Tr { fn f(&self) {} } } } fn g<T: foo::Tr>(t: T) { t.f(); // Currently, this is a privacy error even though `foo::Tr` is visible } ``` After this PR, it will continue to be a privacy error to use a method from a trait that is not visible. This can happen when a public trait inherits from a private trait (in violation of the `public_in_private` lint) -- see @petrochenkov's example in #28504. r? @nikomatsakis
rust-lang/rust#18241 is fixed now, so this mod doesn't need to be pub.
Remove unnecessary pub mod rust-lang/rust#18241 is fixed now, so this mod doesn't need to be pub. Possible downside: the minimum compiler version to build is now 1.9.0 or thereabouts.
Remove unnecessary pub mod rust-lang/rust#18241 is fixed now, so this mod doesn't need to be pub. Possible downside: the minimum compiler version to build is now 1.9.0 or thereabouts.
This was working previously before
rustc 0.13.0-nightly (3d2cf6063 2014-10-22 00:22:04 +0000)
.If this is an intended change, we should probably give the error where the re-export is defined and not on use of the trait.
The text was updated successfully, but these errors were encountered: