[rustdoc] Jump to definition feature tries to infer `cfg`ed-out items

[GuillaumeGomez]

[compiler-errors]

Is this issue gonna get filled out? Seems a bit empty.

[GuillaumeGomez]

For that I need to check why cfg-ed out items are actually processed by rustdoc. My current guess is that the items are still part of the HIR and when we use the HIR visitor, it gives rustdoc the items whereas it shouldn't.

Anyway, on my TODO list.

[fmease]

I presume this issue was created as a counterpart to this FIXME:

rust/src/librustdoc/html/render/span_map.rs

Lines 223 to 226 in 2aabf3c

	// FIXME: this is showing error messages for parts of the code that are not
	// compiled (because of cfg)!
	//
	// See discussion in https://github.com/rust-lang/rust/issues/69426#issuecomment-1019412352

...which I just replaced with the following in PR #156413:

rust/src/librustdoc/html/render/span_map.rs

Lines 108 to 120 in 5ea817c

	/// This will typeck the body if it hasn't been already. Since rustdoc intentionally doesn't run
	/// all semantic analysis passes on function bodies at the time of writing, this can lead to us
	/// "suddenly" rejecting the user's code under `--generate-link-to-definition` while accepting
	/// it if that flag isn't passed! So use this method sparingly and think about the consequences
	/// including performance!
	///
	/// This behavior is documented in the rustdoc book. Ideally, it wouldn't be that way but no
	/// good solution has been found so far. Don't think about adding some sort of flag to rustc to
	/// suppress diagnostic emission that would be unsound wrt. `ErrorGuaranteed`[^1] and generally
	/// be quite hacky!
	///
	/// [^1]: Historical context:
	/// <https://github.com/rust-lang/rust/issues/69426#issuecomment-1019412352>.

...or am I mistaken?

If that were the case then the title of this GH issue needs to be adjusted to no longer mention "cfg'ed out". I haven't found any evidence that would suggest that rustdoc "infer"s or "processes" cfg'ed out items for link-to-definition.

If items are cfg'ed out, they won't be part of the HIR unless rustc's (early) expansion passes screwed up (which I highly doubt) or invoked incorrectly by rustdoc (I doubt that, too, since that would necessarily also affect other parts of rustdoc like local clean'ing which we know is not affected).

[fmease]

To drive the point home, given this crate:

pub fn f0() { std::convert::identity(()); }

fn f1() { std::convert::identity(()); }

#[cfg(false)]
pub fn f2() { std::convert::identity(()); }

#[cfg(false)]
fn f3() { std::convert::identity(()); }

identity in f2 and f3 are correctly ignored by link-to-definition.