rustdoc: Render visibilities succinctly

[camelid]

Fixes#79139.

r? @jyn514

[camelid]

Well, it looks like there's an issue somewhere because about 2/3 of the rustdoc tests are failing! It seems there's some ICEing, I assume from expect_local().

[camelid]

So I guess I'll have to change the approach. I can't just use tcx.parent_module_from_def_id because that requires a LocalDefId, and we're not always documenting local items (e.g. when documenting impls of non-local traits on local types). How do I get the parent module of a non-local item then?

[jyn514]

How do I get the parent module of a non-local item then?

Can you refactor

rust/src/librustdoc/passes/collect_intra_doc_links.rs

Lines 777 to 795 in 1832bdd

	letmut current = item.def_id;
	// The immediate parent might not always be a module.
	// Find the first parent which is.
	loop{
	ifletSome(parent) = self.cx.tcx.parent(current){
	ifself.cx.tcx.def_kind(parent) == DefKind::Mod{
	breakSome(parent);
	}
	current = parent;
	}else{
	debug!(
	"{:?} has no parent (kind={:?}, original was {:?})",
	current,
	self.cx.tcx.def_kind(current),
	item.def_id
	);
	breakNone;
	}
	}

into a function?

[jyn514]

(Ideally that would be part of rustc directly but there was some controversy about that: #77984 (comment))

[camelid]

Ready for another review!

@rustbot label +S-waiting-on-review -S-waiting-on-author

[camelid]

Nominating for beta backport: this fixes a beta regression that makes visibilities shown in the output from --document-private-items verbose and confusing.

[jyn514]

I agree we should backport this, it fixes a regression introduced in 1.50, and happened to miss the cutoff and landed in 1.51 instead.

@rust-lang/rustdoc how do you feel about backporting this?

[camelid]

Also, beta was cut just a few days ago so it's not like beta's about to hit stable: We have time to catch any potential issues.

[GuillaumeGomez]

I think we should backport it as well.

[camelid]

Should this be marked as beta-accepted then?

[GuillaumeGomez]

I *think* it requires someone from the infra. cc @pietroalbini

[camelid]

My understanding (though I may be wrong) is that beta-accepted is used by the team responsible for the code (in this case, T-rustdoc) to say that it should be backported. Then someone (usually Mark-Simulacrum) goes through all the beta-accepted PRs and backports them.

[jyn514]

Oh, I was going to wait for @Manishearth to give an opinion. We as a team should probably come up with some policy for this.

[GuillaumeGomez]

For now, half the members agreed on it so let's add the label. But as many things, we'll need to formalize it.

[emilyalbini]

@GuillaumeGomez so, the policy for beta backports is the following:

1. Someone nominates the PR by adding the beta-nominated label and the relevant team label.
2. That team agrees to the nomination with whatever consensus mechanism they want, applies the beta-accepted label and keeps the beta-nominated label.
3. Someone from the release team looks through all the PRs with both the beta-nominated and beta-accepted labels, backports them and keeps just the beta-accepted label.

[GuillaumeGomez]

Thanks for the information! Is there a document available somewhere with the different processes? It would be very useful.

[emilyalbini]

The docs for backporting is https://forge.rust-lang.org/release/beta-backporting.html. I'm not sure if there is a document describing the processes of each team.

[Mark-Simulacrum]

@camelid just a minor note for the future - would be good to try to rebase before r+ing to squash out any minor fixup commits to try and keep commit history clean :)