rustdoc: Private function is rendered with a verbose visibility

[camelid]

If I run cargo +nightly doc --document-private-items on this code:

mod foo {
    struct S;
    impl S {
        fn new() -> S { S }
    }
}

then the output looks like this:

Note that the visibility is verbose – it says pub(in foo) when it should show nothing (and used to show nothing).

This bug only occurs when the function is private and --document-private-items is passed (of course, the docs are not generated without that flag).

[camelid]

searched nightlies: from nightly-2020-11-17 to nightly-2020-11-20
regressed nightly: nightly-2020-11-19
searched commits: from c919f49 to 8256379
regressed commit: 7d747db

bisected with cargo-bisect-rustc v0.6.0

Host triple: x86_64-apple-darwin
Reproduce with:

cargo bisect-rustc --preserve --prompt --start=2020-11-17 --end=2020-11-20 -- doc --document-private-items 

---

I'm not sure if the commit it thinks has the regression is correct though. cargo-bisect-rustc printed out this during bisection:

installing c4f836ad1aceb83507810d9499f56988fd24578d
installing 87776d7d5322422e5239e153e793b687f7f9c379
installing 7d747db0d5dd8f08f2efb073e2e77a34553465a7
testing...

and then after that it asked me again about c919f49, even though it asked me about it at the start of bisection.

[jyn514]

the visibility is verbose – it says pub(in foo) when it should show nothing

This is probably the same cause as #79139, although the fix may be slightly different.

cargo bisect-rustc --preserve --prompt --start=2020-11-17 --end=2020-11-20 -- doc --document-private-items

The 'prompt' there makes me think you might have hit the wrong 'good/bad' option at some point.

[camelid]

I did the bisection twice though and both times it had the same result. I wish cargo-bisect-rustc could do this automatically somehow.

[jyn514]

@camelid you could write a script that does an xpath query on the generated documentation, maybe.

[camelid]

At that point it's faster to do it manually.

[camelid]

@jyn514 Did the formatting change happen as part of #77820?

[jyn514]

@camelid I wouldn't expect it to but I don't know without bisecting.

[camelid]

I bisected a third time, and again I got the same result. I think it might be a bug in cargo-bisect-rustc.

[jyn514]

Well I can at least confirm that the bug is not present in beta, so this is a nightly regression.

[jyn514]

These are the PRs merged between the 17th and 18th (the 18th also has this bug): https://github.com/rust-lang/rust/pulls?q=is%3Amerged+is%3Apr+label%3AT-rustdoc+merged%3A2020-11-17..2020-11-18. fn new() {} doesn't have the weird formatting so I suspect either #79125 or #77820.

[camelid]

Based on manually installing toolchains, I've confirmed that the issue was introduced in nightly-2020-11-19, so that's c919f49...8256379.

[camelid]

Based on yet more manual testing by installing CI toolchains, I've confirmed that the issue was introduced in c4f836a (#77820). Phew, that was a lot of manual bisection!

[camelid]

I figured out that the reason it has weird formatting is that rustdoc will render functions like

fn foo(
    x: ...,
    y: ...
)

if the one-line version would be over 80 characters.

This is the code that does that conditional formatting:

rust/src/librustdoc/html/format.rs

Line 1064 in 969b42d

let output = if declaration_len > 80 {

So, the reason the weird formatting happens only on private functions is because the visibility is verbose and thus many functions end up being over 80 characters.

We might consider increasing that limit to 100 characters since that's the Rust standard line length, but I'm not sure if that would degrade readability.

[camelid]

Closing as duplicate of #79139.