Add support for range params to rustdoc

[CraftSpider]

Fixes #79497

There's future work to use rustc_hir_pretty for more of what the function does, but this fixes the ICE.

[rust-highfive]

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

[CraftSpider]

Forgot the review.
r? @jyn514

[jyn514]

Also assigning @petrochenkov for the change to rustc_hir_pretty (but the change LGTM).

[petrochenkov]

I think it's better to degrade to _ here than pull HIR pretty-printing, especially given that this case is improbable in practice and only full ranges can be accepted in this position without errors.
This is also true for the PatKind::Lit case above (also warn!ing in that case is not rustdoc's job).

[CraftSpider]

Degrade as in print out _ instead of the actual range, I'm assuming you mean?
I used the pretty-print primarily due to @jyn514's advice that the function should actually, in future work, shift to using it for more of the cases, and rely less on re-implementing logic for it. And I don't think there's any harm to printing the true value, as this case is rare and thus it's not like it should hurt average performance. So if anything, I think the Lit case should also fall back to pretty-print as well.

[petrochenkov]

The general plan for HIR pretty-printing is to either remove or privatize it, some work in this direction was already done in #70344 so it's rarely used now.

rustdoc's goal on the other hand is to print human-readable function parameter names, not to print HIR as precisely as possible.
Literals or ranges don't contain parameter names, so they don't need to be printed.

I'll leave this to @jyn514 to decide.

[jyn514]

The main goal here is to reduce rustc_hir's dependencies and its size such that it can start and finish earlier, thereby working towards #65031.

Rustdoc is built after all rustc crates are built, so it doesn't affect this goal one way or another.

The general plan for HIR pretty-printing is to either remove or privatize it

Can you expand on this? I haven't seen plans to remove it altogether - will it be replaced with something? In this particular case a wildcard seems fine, but I'd like to eventually get rid of this whole function and use param_to_string instead. Would it be better to use that here directly instead of adding more functions to rustc_hir_pretty?

[petrochenkov]

r? @jyn514

[jyn514]

@bors r+

[bors]

📌 Commit 04ccdf1 has been approved by jyn514

[jyn514]

Actually I think #80799 makes more sense so rustc_hir_pretty doesn't have to be expanded.

@bors r-