Ignore rustc_private items from std docs

[tesuji]

By ignoring rustc_private items for non local impl block,
this may fix#74672 and fix#75588 .

This might suppress #76529 if it is simple enough for backport.

[rust-highfive]

r? @GuillaumeGomez

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

[jyn514]

Thanks so much for working on this! Just a few nits.

[jyn514]

Yeah, this comment seems fine. nit: this could be else if so you don't need the early return, but won't block on that

[Mark-Simulacrum]

r? @jyn514

[tesuji]

I removed all the added doc to make this patch smaller to be able to backport.

[jyn514]

I removed all the added doc to make this patch smaller to be able to backport.

Oh, I don't think there's need for that, the comments won't hurt anything. It's logic changes I'm worried about backporting.

@bors r+

on getting this into nightly. Now about getting this into beta: @rust-lang/rustdoc I see three options:

1. Don't backport anything. Beta/stable will be missing Join and other unstable traits (Missing Implementors for Join and Pattern trait in rustdoc #75588), and have some rustc_private traits (impl Deref for EndianSlice appears in std docs #74672). This is IMO the worst outcome.
2. Backport Particially revert #73771 #76529 which is a simple revert. Beta/stable will have Join, but also have other documentation about rustc_private items like gimli traits. This is the most conservative option: it exposes rustc internals, but it makes sure there's no missing docs.
3. Backport this PR. Beta/stable will have Join and will not have rustc_private items, but there's the possibility this introduces a bug by accident.

Personally I'm in favor of 3, but I'm willing to be convinced by 2. What do you think?

[bors]

📌 Commit ccd76110bfcd0339d70f554f5901443dd551fdbf has been approved by jyn514

[jyn514]

cc also @alexcrichton who wrote #73771

[jyn514]

@bors r-

CI is failing, but LGTM when fixed, maybe add back the comments while you're at it

[tesuji]

Fixed the tidy error,

maybe add back the comments while you're at it

I will add them back in other cleanup PRs.

@rustbot modify labels: -S-waiting-on-author +S-waiting-on-review

[tesuji]

@lzutao please don't force push, github now shows a 4k line diff before and after.

Yeah, I'm sorry. But GitHub could improve their compare page.
At local you could run git range-diff c3d048a...c743fc4, it is a lot cleaner.
My local result of that command:

@@ src/tools/linkchecker/main.rs: fn is_exception(file: &Path, link: &str) -> bool
+ // calculated in `check` function is outside `build/<triple>/doc` dir.
+ // So the `strip_prefix` method just returns the old absolute broken path.
+ if file.ends_with("std/primitive.slice.html") {
-+ if link.ends_with("std/primitive.slice.html") {++ if link.ends_with("primitive.slice.html") {
+ return true;
+ }
+ }

What change did you make to fix the tidy error?

I simply removed the "std/" prefix, cause windows path (in this case has type lossy &str) usually has \ as path separators.

[jyn514]

GitHub could improve their compare page. At local you could run git range-diff c3d048a...c743fc4, it is a lot cleaner.

Yeah, I've suggested this before (isaacs/github#1834) but it was ignored.

Ok, the change looks fine.

@bors r+

[bors]

📌 Commit c743fc4 has been approved by jyn514

[tesuji]

Yeah, I've suggested this before (isaacs/github#1834) but it was ignored.

Yeah, that's sad. But I think running range-diff still requires more calculation power than just normal diff.
Consider that github processes thousands of diff requests per second (I guess), it could be a burden for their servers.
Still they could have reply that instead of ignoring the issue.

[bors]

⌛ Testing commit c743fc4 with merge 356d8ad...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: jyn514
Pushing 356d8ad to master...

[tesuji]

Finally! 🎉

[jyn514]

@lzutao to backport this to beta, make a PR with the same commits, but against the beta branch instead of master: https://forge.rust-lang.org/release/beta-backporting.html
Then the rustdoc team will decided whether or not it should be backported.

[jyn514]

@rust-lang/rustdoc this is waiting on a decision about backporting: #76571 (comment)

[GuillaumeGomez]

Is there any reason why we shouldn't? If not I guess it's fine to approve the backport.

[spastorino]

discussed in T-compiler meeting.

@rustbot modify labels: beta-accepted