Code change:
!source_file.is_imported() }) .map(|source_file| { <del> // 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. </del> match source_file.name { <ins> // This path of this SourceFile has been modified by // path-remapping, so we use it verbatim (and avoid // cloning the whole map in the process). _  if source_file.name_was_remapped => source_file.clone(), // Otherwise expand all paths to absolute paths because // any relative paths are potentially relative to a // wrong directory. </ins> FileName::Real(ref name) => { <del> if source_file.name_was_remapped || (name.is_relative() && working_dir_was_remapped) { // This path of this SourceFile has been modified by // path-remapping, so we use it verbatim (and avoid cloning // the whole map in the process). source_file.clone() } else { let mut adapted = (**source_file).clone(); adapted.name = Path::new(&working_dir).join(name).into(); adapted.name_hash = { let mut hasher: StableHasher<u128> = StableHasher::new(); adapted.name.hash(&mut hasher); hasher.finish() }; Lrc::new(adapted) } </del> <ins> let mut adapted = (**source_file).clone(); adapted.name = Path::new(&working_dir).join(name).into(); adapted.name_hash = { let mut hasher: StableHasher<u128> = StableHasher::new(); adapted.name.hash(&mut hasher); hasher.finish() }; Lrc::new(adapted) </ins> }, // expanded code, not from a file _ => source_file.clone(), }

Related discussion:
text: STR (on Linux): file that has generics usage () code DWARF info Notice that contains such entries as , possibly produced by the fact that "" is a relative path and DWATcompdir is set to "/home/yury". It is expected for core files to have absolute path e.g. ""
cc I wonder what interaction (path rewriting?) causes this result.
FWIW, produces that shows that !DIFile entries has the directory field empty (and the filename is relative)
It is a regression, since +stable has absolute locations, e.g.
could this have to do with
Likely so! I'll try to look into this in the near future
Ok so the change here can be exhibited with this script: If you execute that script you see: but if you remove you see: It appears that if upstream crates (like libstd) use then their filename is listed as the original relative source file instead of the absolute path name that it had previous to when it wasn't compiled with . So somehow using 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 (that is the whole point after all) but ideally it'd still be an absolute path, just applying the mapping. 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!
This should be what you're looking for: One solution would be to compile libstd with absolute paths and apply proper remapping to those.
Ah that's perfect! I'll see if I can work up a solution to that soon