[rustdoc] Add support for associated items in "jump to def" feature

[GuillaumeGomez]

Fixes #135485.

r? @fmease

[GuillaumeGomez]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 0a62c9e with merge 884d495...

[bors]

☀️ Try build successful - checks-actions
Build commit: 884d495 (884d4952c02212f92d6d2dd3e1c804fd1aa1cd24)

[GuillaumeGomez]

Second commit is the interesting part: it overloads visit_qpath.

[fmease]

You should now be able to remove the visit_pat and handle_pat methods entirely thanks to this overwrite. Unless I'm forgetting things.

[GuillaumeGomez]

Unfortunately no because of this case:

match self {
    // Doesn't work.
    Self::Ok(_) => {}
    // Works.
    MyEnum::Err(_) => {}
    // Doesn't work
    Self::Some(_) => {}
    // Works.
    Self::None => {}
}

[fmease]

Right, I'm pretty sure that there's a way to do it (by using the maybe_typeck_results pattern I mentioned back then on Zulip). After all, the cleanup part is all about getting rid of {visit,handle}_pat for me personally.

I'm gonna be afk in a sec, so I can't explain the maybe_typeck_results approach rn and I don't know if you can decipher my past rambling on Zulip. Well, you can check out rustc since it uses the "maybe_typeck_results pattern" quite frequently.

[GuillaumeGomez]

It's fine. Gonna give it a try and if I can't gonna let you do it since you seem to have a clear implementation in mind.

[fmease]

I'll experiment later. Ofc, you can always try reading through hir::intravisit and see which methods don't get called in this PR which do get called on master, maybe there's a more obvious 'bug'.

[GuillaumeGomez]

I uncovered the maybe_typeck_results dark arcanes and fixed it. I wonder if there is a shorter way though, code still seems longer than it needs to be...

[fmease]

I'll check that soon. In any case, since this fixes things / adds support for more path types, I'd say it'd be fine even if we couldn't simplify it.

Also, with this method rustdoc should now be able to resolve fully-qualified paths (<$Type as $TraitRef>::$assoc), too, and that in all positions (expr, pat, type). On master, we don't support those at all iirc. However, I haven't double-checked if your impl is sufficient or if you still need to hook up some things. Could you add tests for them if this PR makes them work?

[rust-timer]

Finished benchmarking commit (884d495): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 1.9%, secondary 2.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.9%	[0.8%, 2.9%]	4
Regressions ❌ (secondary)	2.6%	[1.3%, 4.1%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.9%	[0.8%, 2.9%]	4

Cycles

Results (secondary 2.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 767.44s -> 767.097s (-0.04%)
Artifact size: 325.97 MiB -> 326.00 MiB (0.01%)

[GuillaumeGomez]

@bors try @rust-timer queue

[bors]

⌛ Trying commit bcd4e2e with merge 4f36aac...

[bors]

☀️ Try build successful - checks-actions
Build commit: 4f36aac (4f36aac4606855ed0367291dac471c76ff3e5851)

[rust-timer]

Finished benchmarking commit (4f36aac): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 1.8%, secondary 0.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.8%	[1.8%, 1.8%]	1
Regressions ❌ (secondary)	1.9%	[1.8%, 1.9%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.7%	[-2.7%, -2.7%]	1
All ❌✅ (primary)	1.8%	[1.8%, 1.8%]	1

Cycles

Results (secondary -2.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.9%	[-2.9%, -2.9%]	1
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 766.257s -> 767.122s (0.11%)
Artifact size: 325.96 MiB -> 325.97 MiB (0.00%)

[GuillaumeGomez]

Made more changes which had some interesting side-effects: we now have items in a same path that can generate links. However, projections still link to where the item is defined in the trait and not in the trait implementation, which is a bit sad...

You can check it here.

[bors]

☔ The latest upstream changes (presumably #140695) made this pull request unmergeable. Please resolve the merge conflicts.

[GuillaumeGomez]

Fixed merge conflict.

[fmease]

Did it get linkified?

rust-lang:master

Context	Kind	<T as C>::X	<T>::X	<T as C>::X(…)	<T>::X(…)
Item	Ty	❌	❌	n/a	n/a
Item	Ct	❌	n/a (mGCA)	n/a	n/a
Item	Fn (RTN)	n/a	n/a	❌	❌
Expr	Ty	❌	❌	n/a	n/a
Expr	Ct	❌	❌	❌	✅
Expr	Fn	❌	❌	❌	✅
Pat	Ty	n/a	n/a	n/a	n/a
Pat	Ct	❌	n/a (mGCA)	n/a	n/a
Pat	Fn	n/a	n/a	n/a	n/a

GuillaumeGomez:jump-to-def-perf

Context	Kind	<T as C>::X	<T>::X	<T as C>::X(…)	<T>::X(…)
Item	Ty	✅	❌	n/a	n/a
Item	Ct	✅	n/a (mGCA)	n/a	n/a
Item	Fn (RTN)	n/a	n/a	✅	❌
Expr	Ty	✅	❌	n/a	n/a
Expr	Ct	✅	✅	✅	✅
Expr	Fn	✅	✅	✅	✅
Pat	Ty	n/a	n/a	n/a	n/a
Pat	Ct	✅	n/a (mGCA)	n/a	n/a
Pat	Fn	n/a	n/a	n/a	n/a

Code Under Test

#![feature(return_type_notation)]

pub trait Trait {
    type Assoc;
    const ASSOC: usize;
    const ASSOC1: fn();
    fn assoc() -> impl Sized;
}
impl Trait for () {
    type Assoc = ();
    const ASSOC: usize = 0;
    const ASSOC1: fn() = || {};
    fn assoc() -> impl Sized {}
}

pub struct Item0<T: Trait>(pub <T as Trait>::Assoc);
pub struct Item1<T: Trait>(pub T::Assoc);

pub fn expr0<T: Trait>() { let _: <T as Trait>::Assoc; }
pub fn expr1<T: Trait>() { let _: T::Assoc; }

pub struct Item2([(); <() as Trait>::ASSOC]);

pub struct Item3<T: Trait>(T) where <T as Trait>::assoc(..):;
pub struct Item4<T: Trait>(T) where T::assoc(..):;

pub fn expr2<T: Trait>() { _ = <T as Trait>::ASSOC; }
pub fn expr3<T: Trait>() { _ = T::ASSOC; }

pub fn expr4<T: Trait>() { _ = <T as Trait>::assoc; _ = <T as Trait>::assoc(); }
pub fn expr5<T: Trait>() { _ = T::assoc; _ = T::assoc(); }

pub fn pat0() { match 0 { <() as Trait>::ASSOC => {}, _ => {} } }

pub fn expr6<T: Trait>() { _ = <T as Trait>::ASSOC1(); }
pub fn expr7<T: Trait>() { _ = T::ASSOC1(); }

[fmease]

There are still cases that don't work as seen in the table I've created. We can always iterate on this approach.

@bors r+ rollup

[bors]

📌 Commit 687ac3f has been approved by fmease

It is now in the queue for this repository.

[GuillaumeGomez]

Panicked in #144799.

@bors r-