Correctly encode item visibility in metadata #8365
Conversation
|
There are two-ish pain points of this request
|
|
Can the error message be improved later, or is that difficult? |
|
While not impossible, I didn't see a clear way to do them. When I think about it I don't think the privacy checker should exist in its current form today. Right now it runs on the def_id of an invocation and bails out if the item itself is private, but this needs to take into account different scopes of information. Right now, it'd be easiest to shove this check into resolve, but I think resolve doesn't really need to get bigger. One awesome thing which could be done is to completely remove the idea of privacy from resolve and completely leave it up to the privacy checker. The privacy checker would then have to be aware of the module hierarchy, but I don't think that's really too hard. @pcwalton, what do you think about moving privacy completely into Regardless, the error message I think is difficult to improve now, but I like the idea of improving it later on. |
|
It looks good to me but I'm a little worried about reviewing anything in resolve. r? @pcwalton perhaps? |
|
@alexcrichton Yes, I want to move privacy into privacy.rs. Resolve shouldn't know about privacy. (It may change the semantics of |
This fixes private statics and functions from being usable cross-crates
|
r=pcwalton |
|
@alexcrichton The test failure looks legit. |
|
I thought about this a bit, and I'm going to close this for now. I don't want to make resolve any more complicated, so I'm going to try to purge any notion of privacy from resolve and see if I can't re-do this. |
This fixes private statics and functions from being usable cross-crates, along with some bad privacy error messages. This is a reopening of rust-lang#8365 with all the privacy checks in privacy.rs instead of resolve.rs (where they should be anyway). These maps of exported items will hopefully get used for generating documentation by rustdoc Closes rust-lang#8592
…walton This fixes private statics and functions from being usable cross-crates, along with some bad privacy error messages. This is a reopening of #8365 with all the privacy checks in privacy.rs instead of resolve.rs (where they should be anyway). These maps of exported items will hopefully get used for generating documentation by rustdoc Closes #8592
…=camsteffen Add `explicit_write` suggestions for `write!`s with format args changelog: Add [`explicit_write`] suggestions for `write!`s with format args Fixes rust-lang#4542 ```rust writeln!(std::io::stderr(), "macro arg {}", one!()).unwrap(); ``` Now suggests: ``` error: use of `writeln!(stderr(), ...).unwrap()` --> $DIR/explicit_write.rs:36:9 | LL | writeln!(std::io::stderr(), "macro arg {}", one!()).unwrap(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try this: `eprintln!("macro arg {}", one!())` ``` --------- r? `@camsteffen` (again, sorry 😛) for the `FormatArgsExpn` change Before this change `inputs_span` returned a span pointing to just `1` in ```rust macro_rules! one { () => { 1 }; } `writeln!(std::io::stderr(), "macro arg {}", one!()).unwrap();` ``` And the `source_callsite` of that span didn't include the format string, it was just `one!()`
This fixes private statics and functions from being usable cross-crates.
This addresses some concerns about statics being public by default by accident from #8122