resolve: use #[doc(alias)] to improve function resolution diagnostics

[Unique-Usman]

Parse #[doc(alias)] attributes for local functions and store them in the resolver. Use these aliases during name resolution diagnostics to suggest the original function when an alias is used in its place.

This enables cases like calling bar() to suggest foo() when foo is annotated with #[doc(alias = "bar")].

Includes UI tests for function and method cases(which has already being supported).

[rustbot]

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 69 candidates
• Random selection from 10 candidates

[Unique-Usman]

r? estebank

[petrochenkov]

I don't think we should do this.
The alias annotations are targeted at other people using the crate, not the crate's author.
However, the diagnostics here are targeted at the crate's author, the same person who added the alias annotations.
That's what the removed comment says as well.

So it's a low value diagnostic change, but it requires keeping a new global mutable resolver state and doing extra work on a good path -> doesn't pull its weight.

[Unique-Usman]

I don't think we should do this. The alias annotations are targeted at other people using the crate, not the crate's author. However, the diagnostics here are targeted at the crate's author, the same person who added the alias annotations. That's what the removed comment says as well.

Valid point. Not entirely true though, because, doc alias is actually used initially before this pr in the same crate for method and associated functions for diagnostics. Also, the comment was actually also a little bit misleading, after investigating it, the lookup_doc_alias_name was using hir::find_attr! to get the attribute that has been parsed and at that point, we are not yet in hir for same crate so the look_up_doc_alias will panic at that point for function in the same crate while it will work for function in external crate using crate metadata data. Could the reason for not having doc alias for function in the same crate for diagnostics be that it was not sort of possible with the external crate approach ? I asked this because, doc alias for diagnostics works for both extern and same crate works for method and associated function which doc alias attribute was easily gotten as their resolution happens in typecheck hir after attribute panic. So, why have it for method and not function if the doc alias for diagnostics is targeted for people using external and not that because it would cause panic for function ?

So it's a low value diagnostic change, but it requires keeping a new global mutable resolver state and doing extra work on a good path -> doesn't pull its weight.

This is true, but, looking at my reason above, do you think this stills stands ?

[Unique-Usman]

This also works for methods and associated function in a trait for the same crates for diagnosis. So, I believe not working for function is more of the hacking that needs to be done to supportting it.

[petrochenkov]

doc alias is actually used initially before this pr in the same crate for method and associated functions for diagnostics.

Yeah, because there (in compiler\rustc_hir_typeck\src\method\probe.rs I suppose) it's zero-cost, all the attributes (local or not) are already parsed and available, using them for diagnostics doesn't have drawbacks. (Technically we can disable the diagnostics for the local cases there, but is no strong motivation for the either choice, so it's just simpler not to do that.)
Here in rustc_resolve the local attributes are not yet available, that's why you have to introduce and fill a separate table, which is a drawback, so it's simpler to disable the diagnostics for the local case.
I don't think consistency between diagnostics in rustc_hir_typeck and in rustc_resolve is too important.

using hir::find_attr! to get the attribute that has been parsed and at that point, we are not yet in hir for same crate

That's an (ideological) issue with the new attribute parsing infra design, parsed attributes are not HIR, and are often used before HIR is built (like in rustc_resolve), but the new infra uses HIR for naming and puts itself into HIR modules.