Stabilize pub(restricted)

[cramertj]

Fix #32409

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[retep998]

Shouldn't we first just stabilize pub(restricted) so people have time to switch to it before we turn private in public into a hard error?

[cramertj]

@retep998 That seems reasonable to me.

[cramertj]

@retep998 I'll have a new commit up in a minute with that change.

[petrochenkov]

private_in_public can't be turned into an error in the near future unfortunately.
self.tcx.sess.features.borrow().pub_restricted can be well approximated with is_pub_restricted(vis) && is_pub_restricted(self.required_visibility) where is_pub_restricted = not pub && not private.
The idea is to always report an error and not warning when pub(something) is involved.

[cramertj]

What do you mean by not private? Visibility is either Public, Restricted(DefId), or Invisible (reserved for private external items).

[petrochenkov]

You can use hir::Visibility for this (as opposed to ty::Visibility).
For vis HIR visibility is immediately available (item.vis) , for self.required_visibility you can pass it from PrivateItemsInPublicInterfacesVisitor::visit_item to here somehow.

[cramertj]

Even for hir::Visibility, I still only see Public, Crate, Restricted {...}, and Inherited, no Private. Am I missing something obvious?

[petrochenkov]

Inherited is private (i.e. no any explicit pub)

[sfackler]

Beta nominating since I think @aturon was interested in landing this in 1.17.

[nikomatsakis]

I'm not inclined to backport a stabilization -- or at least not this one.

[nikomatsakis]

@bors r+

[bors]

📌 Commit 28626ca has been approved by nikomatsakis

[nikomatsakis]

Note: doc pr is here: rust-lang-nursery/reference#12

[petrochenkov]

Right now this PR turns all private-in-public errors for pub(restricted) into warnings (since they are not in the "old set").
I'd prefer @cramertj to implement #40556 (comment) before merging.

@bors r-

[nikomatsakis]

Hmm. I see. OK, that probably makes sense.

[ubsan]

I disagree with this stabilization. This is a poor implementation of pub(restricted) which has too much power that isn't all that useful for real code, while also being ugly.

[nikomatsakis]

Removing beta-nominated. Seems like there is no need to backport a stabilization, no great urgency.

[ubsan]

Okay, I remove my disagreement, actually (sorry). I read more of the reasoning behind the need for in path, and I can agree that it is useful. (sorry sorry sorry)

[petrochenkov]

@cramertj
A simpler and more precise solution - just walk all the crate's HIR and check if pub(restricted) is ever used.
This can be done in advance even if no errors happen, (almost) no-op HIR walk is super fast and won't affect performance (and this is all temporary anyway).

[cramertj]

@petrochenkov I was just finishing up piping &'tcx hir::Visibility through the whole thing and shaking my head at how much churn wound up being necessary (also made me realize how much I'm dying for static rvalue promotion :) ). This sounds like a much better idea.

Just to make sure I understood you: the process is to add a new visitor which runs in librustc_privacy/lib.rs::check_crate and returns a bool of whether or not pub_restricted was used. If it was, all "private in public" warnings become errors?

[petrochenkov]

Just to make sure I understood you: the process is to add a new visitor which runs in librustc_privacy/lib.rs::check_crate and returns a bool of whether or not pub_restricted was used. If it was, all "private in public" warnings become errors?

Exactly.
That would be equivalent to the previous behavior (modulo unused #![feature(pub_restricted)]s).

[nikomatsakis]

r? @petrochenkov -- since you have something specific in mind =)

[petrochenkov]

@bors r+

[bors]

📌 Commit 60c1c96 has been approved by petrochenkov

[bors]

⌛️ Testing commit 60c1c96 with merge 58c701f...