regression: rustdoc resolution failures

[Mark-Simulacrum]

I think there was some relatively recent work done as part of the work to clean up name resolution inside rustdoc, and there's enough failures that this seems plausible to be a real (if rare) regression. Haven't looked at the surrounding text for these though.

• https://crater-reports.s3.amazonaws.com/beta-1.59-rustdoc-1/beta-2022-01-21/gh/tanium.octobot/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.59-rustdoc-1/beta-2022-01-21/gh/Lymphatus.rusted-caesium/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.59-rustdoc-1/beta-2022-01-21/reg/arrsingh-0.19.0/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.59-rustdoc-1/beta-2022-01-21/reg/deepmesa-0.9.0/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.59-rustdoc-1/beta-2022-01-21/reg/textwrap-macros-0.2.5/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.59-rustdoc-1/beta-2022-01-21/reg/deepmesa-0.9.0/log.txt

cc @petrochenkov @rust-lang/rustdoc

[Nemo157]

It seems like cargo is not building all the dependencies or passing the --extern flags to the rustdoc invocation for some reason.

[Nemo157]

At least some of the dependencies I've checked (textwrap-macros-impl and deepmesa-collections) have set lib.doc = false in their Cargo.toml; maybe related?

[Mark-Simulacrum]

cc @ehuss -- I think this was recently fixed and backported, right?

[Nemo157]

Ah yes, updating to 1.59.0-beta.4 the deepmesa and textwrap-macros builds succeed, it looks like the crater run was on beta.3.

[Mark-Simulacrum]

OK, closing as fixed then.