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.

Sign up for GitHub

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

Jump to bottom

Private items with a public reexport could suggest the public path in privacy error message #13065

Open
huonw opened this issue Mar 22, 2014 · 5 comments
Open

Private items with a public reexport could suggest the public path in privacy error message #13065

huonw opened this issue Mar 22, 2014 · 5 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-resolve Area: Name/path resolution done by `rustc_resolve` specifically C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@huonw
Copy link
Member

huonw commented Mar 22, 2014

E.g. use std::io::buffered::BufferedReader; says struct BufferedReader is private but could say

struct BufferedReader is private, but available publicly as `std::io::BufferedReader`

(This probably requires some significant work, for not a huge benefit.)
@alexcrichton alexcrichton mentioned this issue May 2, 2014
Merged
bors added a commit that referenced this issue May 7, 2014
@bors
auto merge of #13901 : alexcrichton/rust/facade, r=brson
87115fd 
This is the second step in implementing #13851. This PR cannot currently land until a snapshot exists with #13892, but I imagine that this review will take longer.

This PR refactors a large amount of functionality outside of the standard library into a new library, libcore. This new library has 0 dependencies (in theory). In practice, this library currently depends on these symbols being available:

* `rust_begin_unwind` and `rust_fail_bounds_check` - These are the two entry points of failure in libcore. The symbols are provided by libstd currently. In the future (see the bullets on #13851) this will be officially supported with nice error mesages. Additionally, there will only be one failure entry point once `std::fmt` migrates to libcore.
* `memcpy` - This is often generated by LLVM. This is also quite trivial to implement for any platform, so I'm not too worried about this.
* `memcmp` - This is required for comparing strings. This function is quite common *everywhere*, so I don't feel to bad about relying on a consumer of libcore to define it.
* `malloc` and `free` - This is quite unfortunate, and is a temporary stopgap until we deal with the `~` situation. More details can be found in the module `core::should_not_exist`
* `fmod` and `fmodf` - These exist because the `Rem` trait is defined in libcore, so the `Rem` implementation for floats must also be defined in libcore. I imagine that any platform using floating-point modulus will have these symbols anyway, and otherwise they will be optimized out.
* `fdim` and `fdimf` - Like `fmod`, these are from the `Signed` trait being defined in libcore. I don't expect this to be much of a problem

These dependencies all "Just Work" for now because libcore only exists as an rlib, not as a dylib.

The commits themselves are organized to show that the overall diff of this extraction is not all that large. Most modules were able to be moved with very few modifications. The primary module left out of this iteration is `std::fmt`. I plan on migrating the `fmt` module to libcore, but I chose to not do so at this time because it had implications on the `Writer` trait that I wanted to deal with in isolation. There are a few breaking changes in these commits, but they are fairly minor, and are all labeled with `[breaking-change]`.

The nastiest parts of this movement come up with `~[T]` and `~str` being language-defined types today. I believe that much of this nastiness will get better over time as we migrate towards `Vec<T>` and `Str` (or whatever the types will be named). There will likely always be some extension traits, but the situation won't be as bad as it is today.

Known deficiencies:

* rustdoc will get worse in terms of readability. This is the next issue I will tackle as part of #13851. If others think that the rustdoc change should happen first, I can also table this to fix rustdoc first.
* The compiler reveals that all these types are reexports via error messages like `core::option::Option`. This is filed as #13065, and I believe that issue would have a higher priority now. I do not currently plan on fixing that as part of #13851. If others believe that this issue should be fixed, I can also place it on the roadmap for #13851.

I recommend viewing these changes on a commit-by-commit basis. The overall change is likely too overwhelming to take in.
@ghost ghost mentioned this issue Mar 9, 2015
Closed
@steveklabnik
Copy link
Member

Triage: no change here, these kinds of messages still happen.

@steveklabnik steveklabnik added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Apr 28, 2015
@pmarcelll pmarcelll mentioned this issue Jul 4, 2015
Closed
@pnkfelix pnkfelix mentioned this issue Jul 9, 2015
Closed
@bstrie bstrie mentioned this issue Nov 28, 2015
Closed
@steveklabnik
Copy link
Member

Triage: no change

@steveklabnik steveklabnik added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 9, 2017
@steveklabnik
Copy link
Member

Triage: no change

@jonas-schievink jonas-schievink added the A-resolve Area: Name/path resolution done by `rustc_resolve` specifically label Jan 12, 2020
@wbl wbl mentioned this issue Feb 5, 2020
Closed
@rylev
Copy link
Member

rylev commented Jul 5, 2021

Triage: no change

@TimJentzsch
Copy link

TimJentzsch commented Aug 11, 2022 •
edited
Loading

Current output: no real change with 1.65.0-nightly (2022-08-10 29e4a9ee0253cd39e552):

use std::io::buffered::BufReader;
error[[E0603]](https://doc.rust-lang.org/nightly/error-index.html#E0603): module `buffered` is private
 --> src/lib.rs:1:14
  |
1 | [use std::io::buffered::BufReader;](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021#)
  |              ^^^^^^^^ private module
  |
note: the module `buffered` is defined here

lnicola pushed a commit to lnicola/rust that referenced this issue Aug 23, 2022
@bors
Auto merge of rust-lang#13065 - RalfJung:override-command-docs, r=Vey…
c32ab97 
…kril

document interaction of checkOnSave.overrideCommand and multiple linked projects

Cc rust-lang/rust-analyzer#10793

r? `@Veykril`
flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 25, 2024
@bors
Auto merge of rust-lang#13065 - Jarcho:misc_small2, r=xFrednet
637d39f 
Misc refactorings part 2

A couple of theses are a bit more involved. No behaviour changes included in this set.

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-resolve Area: Name/path resolution done by `rustc_resolve` specifically C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@steveklabnik @huonw @rylev @jonas-schievink @TimJentzsch