DWARF information does not contain absolute file locations for generics

[yurydelendik]

STR (on Linux):

1. Create hey.rs file that has generics usage (wget https://raw.githubusercontent.com/yurydelendik/old-man-sandbox/master/rust-wasm-hey/hey.rs)
2. Compile code rustc +nightly hey.rs --crate-type=cdylib -g -o hey
3. Dump DWARF info llvm-dwarfdump hey -debug-info -debug-line > hey.txt

Notice that hey.txt contains such entries as DW_AT_decl_file ("/home/yury/liballoc/vec.rs"), possibly produced by the fact that "liballoc/vec.rs" is a relative path and DW_AT_comp_dir is set to "/home/yury".

It is expected for core files to have absolute path e.g. "/rustc/20dc0c50704ba1fc8c56a88ae2bf05ddb3e419bc/src/liballoc/raw_vec.rs"

[eddyb]

cc @michaelwoerister @tromey I wonder what interaction (path rewriting?) causes this result.

[yurydelendik]

FWIW, rustc +nightly hey.rs --crate-type=cdylib -g --emit=llvm-ir -o hey.ll produces hey.ll that shows that !DIFile entries has the directory field empty (and the filename is relative)

[yurydelendik]

It is a regression, since +stable has absolute locations, e.g. !47 = !DIFile(filename: "/Users/travis/build/rust-lang/rust/src/libcore/ptr.rs", directory: "")

[michaelwoerister]

@alexcrichton, could this have to do with #53829?

[alexcrichton]

Likely so! I'll try to look into this in the near future

[alexcrichton]

Ok so the change here can be exhibited with this script:

set -e

cat > foo.rs <<-EOF
#![crate_type = "lib"]
#[inline]
pub fn foo() {}
EOF

cat > bar.rs <<-EOF
#![crate_type = "cdylib"]
extern crate foo;
#[no_mangle]
pub extern fn bar() { foo::foo() }
EOF

rm -rf tmp
mkdir tmp
rustc -g foo.rs --out-dir tmp --remap-path-prefix=`pwd`=/another
rustc -g bar.rs --out-dir tmp -L tmp --emit llvm-ir

rg DIFile tmp/bar.ll

If you execute that script you see:

33:!1 = !DIFile(filename: "bar.rs", directory: "/home/alex/code/rust3")
37:!5 = !DIFile(filename: "foo.rs", directory: "")

but if you remove --remap-path-prefix you see:

33:!1 = !DIFile(filename: "bar.rs", directory: "/home/alex/code/rust3")
37:!5 = !DIFile(filename: "/home/alex/code/rust3/foo.rs", directory: "")

It appears that if upstream crates (like libstd) use --remap-path-prefix then their filename is listed as the original relative source file instead of the absolute path name that it had previous to #53829 when it wasn't compiled with --remap-path-prefix.

So somehow using --remap-path-prefix to compile libstd is affecting downstream crates to have relative path names instead of old absolute path names. It makes sense to me that the absolute path name goes away with --remap-path-prefix (that is the whole point after all) but ideally it'd still be an absolute path, just applying the mapping.

@michaelwoerister would you be able to help point me in the direction of where this change in logic might happen? If so I can test out a patch!

[michaelwoerister]

@alexcrichton This should be what you're looking for:

rust/src/librustc_metadata/encoder.rs

Lines 352 to 358 in e999ebd

	// When exporting SourceFiles, we expand all paths to absolute
	// paths because any relative paths are potentially relative to
	// a wrong directory.
	// However, if a path has been modified via
	// `--remap-path-prefix` we assume the user has already set
	// things up the way they want and don't touch the path values
	// anymore.

One solution would be to compile libstd with absolute paths and apply proper remapping to those.

[alexcrichton]

Ah that's perfect! I'll see if I can work up a solution to that soon