privacy: Substitute type aliases in private-in-public checker #34193

petrochenkov · 2016-06-09T23:43:32Z

Everyone in the issue discussion seemed to be in favor, @huonw also spoke about this here, but the issue haven't got any movement.
I think it's reasonable to do this before turning private_in_public warnings into errors.

r? @nikomatsakis

jseyfried · 2016-06-12T21:23:10Z

src/test/compile-fail/private-in-public-warn.rs

@@ -246,6 +245,8 @@ mod aliases_priv {
    use self::Priv1 as PrivUseAlias;
    use self::PrivTr1 as PrivUseAliasTr;
    type PrivAlias = Priv2;
+    //~^ WARN private type in public interface
+    //~| WARNING hard error


I'm having trouble seeing why this is an error.

Priv2 is used in a public interface through an alias.
The error location here is suboptimal. On one hand Priv2 is the true source of the error and pointing to PrivAlias is misleading, on the other hand pointing to Priv2 is confusing too, because the public interface it's used in is not pointed to.
Ideally, there should be two diagnostic messages - one for the public interface location and the other for actual private type location. I'll implement this if positive decision about the whole PR is made.

Ahh, makes sense.

I'm confused a bit. This seems like it's causing a new error?

This seems like it's causing a new error?

No, the error from line 211 (alias location) migrated to this line (aliased type location).

Ideally, there should be two diagnostic messages - one for the public interface location and the other for actual private type location.

I implemented the extra note for the private type location for type aliases, but dropped it, the situation should be rare, likely happens in advanced code and doesn't worth the extra code.
Now the error is reported at the public interface location only.

nikomatsakis · 2016-06-27T16:17:12Z

src/test/compile-fail/private-in-public.rs

@@ -105,8 +105,6 @@ mod aliases_pub {
    }
    impl PrivTr for Priv {}

-    // This should be OK, if type aliases are substituted
-    pub fn f2(arg: PrivAlias) {} //~ ERROR private type in public interface


can we add a test to show that no error results?

It's tested, the check is just moved from this file to private-in-public-warn.rs

nikomatsakis · 2016-06-27T16:19:22Z

Ideally, we would fix rustdoc to not use private type aliases as part of this PR.

petrochenkov · 2016-06-28T22:38:47Z

Ideally, we would fix rustdoc to not use private type aliases as part of this PR.

I'll try to fix this and the error locations tomorrow. If I won't be able to, it'll have to wait for another week or so. (I also don't think these are blockers for merging the PR)

petrochenkov · 2016-07-03T14:39:04Z

fix rustdoc to not use private type aliases

Curiously, rustdoc doesn't currently substitute private use aliases.

use std::result::Result as MyResult;
pub fn get_result() -> MyResult<u8, u16> { // Still displayed as MyResult by rustdoc
    panic!();
}

nikomatsakis · 2016-07-07T17:46:54Z

@petrochenkov I guess it's debatable what's the right thing to do there. I mean, the link still goes to the right place, I guess, and it's not clear that showing the full path will help readability overall. (And the full path in that crate may not be the same as the full path from another crate.) In any case, it feels different, because MyResult is a name the user can use, even if their path to it is different.

petrochenkov · 2016-07-08T09:20:44Z

Updated with rustdoc changes and tweaked error locations.

bors · 2016-07-15T19:46:20Z

☔ The latest upstream changes (presumably #34570) made this pull request unmergeable. Please resolve the merge conflicts.

petrochenkov · 2016-07-15T20:41:40Z

Rebased.

nikomatsakis · 2016-08-10T20:21:43Z

src/librustdoc/clean/mod.rs

@@ -1644,8 +1683,46 @@ impl Clean<Type> for hir::Ty {
                FixedVector(box ty.clean(cx), n)
            },
            TyTup(ref tys) => Tuple(tys.clean(cx)),
-            TyPath(None, ref p) => {
-                resolve_type(cx, p.clean(cx), self.id)
+            TyPath(None, ref path) => {


will this logic work if you have a private type alias that refers to another private type alias?

e.g., type A = u32; type B = A; fn foo(x: B) { }?

(Can you also add some tests for that scenario? I could imagine that even if your patch gets it right, it's something future patches might easily break.)

nikomatsakis · 2016-08-10T20:22:01Z

r=me once new tests are added for recursive scenario

…ublic interface location

petrochenkov · 2016-08-10T22:17:15Z

Updated with a test for recursive substitution.

nikomatsakis · 2016-08-11T14:44:23Z

@bors r+

bors · 2016-08-11T14:44:24Z

📌 Commit 5d4ae4b has been approved by nikomatsakis

bors · 2016-08-11T17:09:11Z

⌛ Testing commit 5d4ae4b with merge 11f8805...

@huonw

privacy: Substitute type aliases in private-in-public checker Closes #30503 Closes #34293 Everyone in the issue discussion seemed to be in favor, @huonw also spoke about this [here](https://www.reddit.com/r/rust/comments/3xldr9/surfaces_and_signatures_component_privacy_versus/cy615wq), but the issue haven't got any movement. I think it's reasonable to do this before turning `private_in_public` warnings into errors. r? @nikomatsakis

bors · 2016-08-11T20:14:26Z

rust-highfive assigned nikomatsakis Jun 9, 2016

jseyfried reviewed Jun 12, 2016
View reviewed changes

petrochenkov mentioned this pull request Jun 16, 2016

Rust complains about "private type in public interface" even though the type and interface are both aliases. #34293

Closed

nikomatsakis reviewed Jun 27, 2016
View reviewed changes

petrochenkov force-pushed the privalias branch from 3657e37 to af0df95 Compare June 28, 2016 22:47

nikomatsakis mentioned this pull request Jul 1, 2016

Make private_in_public compatibility lint deny-by-default #34206

Merged

petrochenkov force-pushed the privalias branch from af0df95 to 5679896 Compare July 8, 2016 09:19

petrochenkov force-pushed the privalias branch from 5679896 to 91063fc Compare July 15, 2016 20:41

nikomatsakis reviewed Aug 10, 2016
View reviewed changes

petrochenkov added 4 commits August 11, 2016 00:32

privacy: Substitute type aliases in private-in-public checker

b7db9e8

Substitute private type aliases in rustdoc

08f0f7c

privacy: Move private-in-public diagnostics for type aliases to the p…

d43b9cb

…ublic interface location

Add test for recursive private alias substitution in rustdoc

5d4ae4b

petrochenkov force-pushed the privalias branch from 91063fc to 5d4ae4b Compare August 10, 2016 21:52

bors merged commit 5d4ae4b into rust-lang:master Aug 11, 2016

petrochenkov deleted the privalias branch September 21, 2016 20:01

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

privacy: Substitute type aliases in private-in-public checker #34193

privacy: Substitute type aliases in private-in-public checker #34193

petrochenkov commented Jun 9, 2016 •

edited

Loading

jseyfried Jun 12, 2016

petrochenkov Jun 12, 2016 •

edited

Loading

jseyfried Jun 12, 2016

nikomatsakis Jun 27, 2016

petrochenkov Jun 28, 2016

petrochenkov Jul 8, 2016

nikomatsakis Jun 27, 2016

petrochenkov Jun 28, 2016

nikomatsakis commented Jun 27, 2016

petrochenkov commented Jun 28, 2016 •

edited

Loading

petrochenkov commented Jul 3, 2016

nikomatsakis commented Jul 7, 2016

petrochenkov commented Jul 8, 2016

bors commented Jul 15, 2016

petrochenkov commented Jul 15, 2016

nikomatsakis Aug 10, 2016

nikomatsakis commented Aug 10, 2016

petrochenkov commented Aug 10, 2016

nikomatsakis commented Aug 11, 2016

bors commented Aug 11, 2016

bors commented Aug 11, 2016

bors commented Aug 11, 2016

privacy: Substitute type aliases in private-in-public checker #34193

privacy: Substitute type aliases in private-in-public checker #34193

Conversation

petrochenkov commented Jun 9, 2016 • edited Loading

Choose a reason for hiding this comment

petrochenkov Jun 12, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Jun 27, 2016

petrochenkov commented Jun 28, 2016 • edited Loading

petrochenkov commented Jul 3, 2016

nikomatsakis commented Jul 7, 2016

petrochenkov commented Jul 8, 2016

bors commented Jul 15, 2016

petrochenkov commented Jul 15, 2016

Choose a reason for hiding this comment

nikomatsakis commented Aug 10, 2016

petrochenkov commented Aug 10, 2016

nikomatsakis commented Aug 11, 2016

bors commented Aug 11, 2016

bors commented Aug 11, 2016

bors commented Aug 11, 2016

petrochenkov commented Jun 9, 2016 •

edited

Loading

petrochenkov Jun 12, 2016 •

edited

Loading

petrochenkov commented Jun 28, 2016 •

edited

Loading