Repository navigation
num: remove pub from sub-crates - #190
Merged
Merged
Conversation
Rust 1.4 through 1.7 will issue warnings that `pub extern crate` does not work as expected, although it appears to be fine. But Rust 1.8 and later issue `#[warn(private_in_public)]` for `pub use num_foo as foo` if that crate isn't public, and that's headed toward a hard error. @bluss suggested instead `pub mod foo { pub use num_foo::*; }`, which I thought I had tried before, but it appears to work fine on all versions of Rust. Let's do it! A small downside is that docs for `num::foo` now just show the wildcard reexport, instead of direct documentation, but at least there's a link to follow to the sub-crate. It's a breaking change that `num::num_foo` paths are no longer public, but we didn't really want those exposed in the first place. I consider this minor -- people should either use the `num::foo` module as before the split-up, or use the `num_foo` crate directly. Fixes #189.
Contributor
|
I only mentioned it exists, don't know if it will work well. |
Member
Author
|
That's partly why I opened a PR instead of pushing this right away. It looks fine so far. |
Member
Author
|
@homu r+ |
Contributor
|
📌 Commit 865c491 has been approved by |
homu
added a commit
that referenced
this pull request
May 12, 2016
num: remove `pub` from sub-crates Rust 1.4 through 1.7 will issue warnings that `pub extern crate` does not work as expected, although it appears to be fine. But Rust 1.8 and later issue `#[warn(private_in_public)]` for `pub use num_foo as foo` if that crate isn't public, and that's headed toward a hard error. @bluss suggested instead `pub mod foo { pub use num_foo::*; }`, which I thought I had tried before, but it appears to work fine on all versions of Rust. Let's do it! A small downside is that docs for `num::foo` now just show the wildcard reexport, instead of direct documentation, but at least there's a link to follow to the sub-crate. It's a breaking change that `num::num_foo` paths are no longer public, but we didn't really want those exposed in the first place. I consider this minor -- people should either use the `num::foo` module as before the split-up, or use the `num_foo` crate directly. Fixes #189.
Member
|
In Octavo I am using |
Member
Author
|
Sure, that would be nice, but it runs afoul of the same warning as #189 in older rustc. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rust 1.4 through 1.7 will issue warnings that
pub extern cratedoesnot work as expected, although it appears to be fine. But Rust 1.8 and
later issue
#[warn(private_in_public)]forpub use num_foo as fooifthat crate isn't public, and that's headed toward a hard error.
@bluss suggested instead
pub mod foo { pub use num_foo::*; }, whichI thought I had tried before, but it appears to work fine on all
versions of Rust. Let's do it!
A small downside is that docs for
num::foonow just show the wildcardreexport, instead of direct documentation, but at least there's a link
to follow to the sub-crate.
It's a breaking change that
num::num_foopaths are no longer public,but we didn't really want those exposed in the first place. I consider
this minor -- people should either use the
num::foomodule as beforethe split-up, or use the
num_foocrate directly.Fixes #189.