rustdoc: turn is_unnamable into a compiler query

[lolbinarycat]

as discussed in #143849 (comment)

first time adding a compiler query, so i'm not sure if i have all the options and caching strategies configured right.

need someone to run a perf job for me on this.

once this is merged i may send a followup to also use this query to inhibit normalization into unnamable types.

as discussed in #143849 (comment)

r? @GuillaumeGomez

[GuillaumeGomez]

What do you think about:

Suggested change

	/// Checks if the given defid refers to an item that is unnamable, such as one defined in a const block.
	/// Checks if the given `DefId` refers to an unnamable item like:
	///
	/// ```
	/// pub fn f() {
	/// // In here, `X` is not reachable outside of `f`, making it unnamable.
	/// pub struct X;
	/// }
	/// ```

[lolbinarycat]

The problem is that the rustdoc module view and possibly some IDEs will just show "Checks if the given DefId refers to an unnamable item like:" as the summary.

In any case, this is the private query implementation, so any in-depth doc comment should probably go on the query itself so it can easily be found.

[GuillaumeGomez]

I'd advise to put the doc comment in both places then. :)

Also, I don't have an IDE providing doc comments for an item (which sounds really nice) but I don't think it's an argument in favor of having shorter doc comments. More like a bug to report on the IDE.

[lolbinarycat]

I'm not advising for shorter docs, I'm just trying to follow the official style guide for docs.

The point is the first sentence needs to make sense on its own.

[GuillaumeGomez]

I'm not advising for shorter docs, I'm just trying to follow the official style guide for docs.

Which I co-wrote. I'm ashamed. You're absolutely right.

What about:

Suggested change

	/// Checks if the given defid refers to an item that is unnamable, such as one defined in a const block.
	/// Checks if the given `DefId` refers to an unnamable item, such as one defined in a function.
	///
	/// Example:
	///
	/// ```
	/// pub fn f() {
	/// // In here, `X` is not reachable outside of `f`, making it unnamable.
	/// pub struct X;
	/// }
	/// ```

[lolbinarycat]

That's incredibly similar to what I just pushed, curious if you think that's good enough.

[GuillaumeGomez]

Might be better to have someone more used to compiler queries to ensure it's all good.

r? oli-obk

[rustbot]

oli-obk is not on the review rotation at the moment.
They may take a while to respond.

[GuillaumeGomez]

@bors2 try @rust-timer queue

[rust-bors]

⌛ Trying commit 497d2c4 with merge 787c9d7…

To cancel the try build, run the command @bors try cancel.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 787c9d7 (787c9d7e38acab303eaa25b513554d777e1e9ca3, parent: 29cdc6a109ee98a382f974bf89d3971b4385399c)

[rust-timer]

Finished benchmarking commit (787c9d7): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.6%	[0.5%, 0.6%]	3
Improvements ✅ (primary)	-0.3%	[-0.5%, -0.2%]	12
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
All ❌✅ (primary)	-0.3%	[-0.5%, -0.2%]	12

Max RSS (memory usage)

Results (primary -2.8%, secondary 2.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.6%	[2.6%, 2.6%]	1
Improvements ✅ (primary)	-2.8%	[-6.3%, -1.0%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.8%	[-6.3%, -1.0%]	3

Cycles

Results (primary 5.7%, secondary -0.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	5.7%	[5.7%, 5.7%]	1
Regressions ❌ (secondary)	2.8%	[2.8%, 2.8%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.5%	[-2.6%, -2.3%]	2
All ❌✅ (primary)	5.7%	[5.7%, 5.7%]	1

Binary size

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

Bootstrap: 464.98s -> 464.656s (-0.07%)
Artifact size: 377.39 MiB -> 377.37 MiB (-0.01%)

[GuillaumeGomez]

The perf gain is much smaller than I hoped though. :-/

[lolbinarycat]

I think it might be possible to return to the idea of running is_unnamable only when needed, but we'll need to run it at normalization and when displaying associated types in traits, which may require a little bit more work.

[cjgillot]

Could you put this in compiler/rustc_interface/src/passes.rs? compiler/rustc_interface/src/queries.rs refers to a completely different kind of queries, that were eventually extinguished.

[cjgillot]

Do we need docs here when we have the query's?