Rustdoc support API in rustc

[oli-obk]

#59789 reverts some changes made to rustc internals that were rustdoc specific (and would be wrong if the compiler actually ended up using these changes, even if they solve a rustdoc problem).

Ideally we'd expose some rustdoc_foo methods that offer exactly what rustdoc needs, instead of changing the regular compiler-code.

cc @rust-lang/compiler @rust-lang/rustdoc

[eddyb]

Ideally we'd expose some rustdoc_foo methods that offer exactly what rustdoc needs, instead of changing the regular compiler-code.

I disagree, the changes were unnecessary, or in the wrong part of the codebase.

There is nothing wrong to supporting the explicit_predicates_of query cross-crate, for example, but adding a hack to the local crate version of the query, to redirect it to predicates_of, without even at least a // HACK comment, is not the way to do it.

[eddyb]

To restate that last bit (about // HACK) a bit more clearly: these were additions, which (even if they weren't wrong / unnecessary), were still not documented as rustdoc-specific hacks.

That means it wouldn't have been clear how to refactor the code later without looking at the commit history.

This is a risk we shouldn't take IMO, and non-rustc changes that touch rustc crates should require more scrutiny, rustdoc just happens to be where I've noticed this problem.

[GuillaumeGomez]

For the non-local items issue: I asked about it (but not clearly enough, my bad) here. ;)

I'm all for supporting explicit_predicates_of for non-local items as well! :)

About making a rustdoc interface: not sure it is a good idea (I lack skills to confidently make such a statement though) since it'd force to support yet another interface. What I'd prefer would be a way for rustdoc contributors to avoid making too much changes into rustc internals. It generally ends up being a lot of questions asked to the compiler team members and the result are generally not completely satisfying for both sides. No clue how such a thing would be possible unfortunately...

[eddyb]

For questions, please PM me on IRC or Discord, even if I'm not active in all channels.

[GuillaumeGomez]

I think I'll go for private messages directly then.

[pnkfelix]

nominating for discussion at rustc meeting: I want to know if there's actual action items here that we are planning to take, or if we are going to consider this an artifact of an (exceptional?) process failure.

[nikomatsakis]

Some thoughts from the recent compiler meeting:

I think identifying functionality that is rustdoc specific with rustdoc_ makes sense in general. One such example that comes to mind is the "autotrait finding" code that we landed.

I also think that -- longer term -- it would be great if we tried to create a consistent, stable-ish query API that tools like rustdoc, clippy, the RLS, and other things could use. This has been a long-standing goal but it's a non-trivial design effort to do.

I'm not exactly sure what the goal of this specific issue is, though, it's probably not that broad.