Rustdoc doesn't show src button for many functions in the rustc docs

[bjorn3]

https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html

[bjorn3]

@rustbot modify labels:+C-bug +T-rustdoc

[ehuss]

I have narrowed this down to #66364. There some interaction between remap-path-prefix and macros in a dependency.

Repro:

cargo new --lib foo
cd foo
cargo new --lib dep
rm dep/src/lib.rs
cat << EOF > dep/src/lib.rs
#[macro_export]
macro_rules! make_item {
    () => {
        pub fn f() {}
    }
}
EOF

echo 'dep = {path="dep"}' >> Cargo.toml
echo 'dep::make_item!{}' >> src/lib.rs
RUSTFLAGS="--remap-path-prefix=`pwd`=/" cargo doc -v  --no-deps

This emits a warning:

warning: source code was requested to be rendered, but processing `/dep/src/lib.rs` had an error: "/dep/src/lib.rs": No such file or directory (os error 2)

and the [src] links don't exist.

If you want to repro with the rustc sources, set remap-debuginfo = true and compiler-docs = true in config.toml and build the rustc docs.

@Centril can you maybe take a look at why this is now broken?

[Centril]

For now, I'll cc @GuillaumeGomez @eddyb @petrochenkov who probably know more about this than I.

[Centril]

I did a bit of investigation. In https://github.com/rust-lang/rust/pull/66364/files#diff-2b18e583c8286c5f266dcc0aea004e91, we have:

-        let def = data.get_macro(id.index);
-        let macro_full_name = data.def_path(id.index).to_string_friendly(|_| data.root.name);
-        let source_name = FileName::Macros(macro_full_name);
-
-        let source_file = sess.parse_sess.source_map().new_source_file(source_name, def.body);
-        let local_span = Span::with_root_ctxt(source_file.start_pos, source_file.end_pos);
-        let dspan = DelimSpan::from_single(local_span);
-        let (body, mut errors) = source_file_to_stream(&sess.parse_sess, source_file, None);
-        emit_unclosed_delims(&mut errors, &sess.parse_sess);
+        let span = data.get_span(id.index, sess);
+        let dspan = DelimSpan::from_single(span);
+        let rmeta::MacroDef { body, legacy } = data.get_macro(id.index, sess);

Note in particular the .new_source_file(source_name, def.body) call, which results in a call to https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html#method.try_new_source_file, which has:

        let (filename, was_remapped) = match filename {
            FileName::Real(filename) => {
                let (filename, was_remapped) = self.path_mapping.map_prefix(filename);
                (FileName::Real(filename), was_remapped)
            }
            other => (other, false),
        };

In particular:

                let (filename, was_remapped) = self.path_mapping.map_prefix(filename);

This seems like it could be the significant change here, but I'm not sure.

[Centril]

Also relevant:

rust/src/librustdoc/html/sources.rs

Lines 35 to 55 in 2113659

	// If we're including source files, and we haven't seen this file yet,
	// then we need to render it out to the filesystem.
	if self.scx.include_sources
	// skip all synthetic "files"
	&& item.source.filename.is_real()
	// skip non-local items
	&& item.def_id.is_local()
	{
	// If it turns out that we couldn't read this file, then we probably
	// can't read any of the files (generating html output from json or
	// something like that), so just don't include sources for the
	// entire crate. The other option is maintaining this mapping on a
	// per-file basis, but that's probably not worth it...
	self.scx.include_sources = match self.emit_source(&item.source.filename) {
	Ok(()) => true,
	Err(e) => {
	println!(
	"warning: source code was requested to be rendered, \
	but processing `{}` had an error: {}",
	item.source.filename, e
	);

[eddyb]

Hang on, but there should be no macros involved in the impl @bjorn3 posted, how is #66364 relevant?

[bjorn3]

That code sets self.scx.include_sources to false when any file could not be read.

[eddyb]

Oh, that's just bad UX and should be fixed independently on not being able to load some file.

[eddyb]

@Mark-Simulacrum Is there any way to use the try build on #70642 to check if it fixes this issue?
i.e. does it include any docs?

[Mark-Simulacrum]

I think it should, but not sure. We have a try build going and once that's done IIRC a command like rustup-toolchain-install-master 40f2b445cd1c6c4e72d663d23c6d1bef2c674ad4 -c rust-docs should work, I believe.