remap-path-prefix appears to be applied in a reverse order

[nagisa]

It appears that if multiple--remap-path-prefix arguments are supplied on the CLI, they will be applied in the reverse order, rather than in the CLI-occurence order.

To reproduce:

$ mkdir -p apple/banana
$ echo 'fn main(){ panic!() }' > apple/banana/chaenomeles.rs
$ rustc apple/banana/chaenomeles.rs --remap-path-prefix=apple/banana/=/first/ --remap-path-prefix=apple/=/second/
$ ./chaenomeles
thread 'main' panicked at 'explicit panic', /second/banana/chaenomeles.rs:1:12
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Note that only the latter --remap-path-prefix got invoked and the panic path became /second/banana/chaenomeles.rs. Instead users need to specify the order of remappings in reverse:

$ rustc apple/banana/chaenomeles.rs --remap-path-prefix=apple/=/first/ --remap-path-prefix=apple/banana/=/second/
$ ./chaenomeles
thread 'main' panicked at 'explicit panic', /second/chaenomeles.rs:1:12
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

(in contrast clang/gcc will apply remappings front-to-back)

[nagisa]

Unclear to me if we can fix this, however, so perhaps we should warn if people write more specific paths first and less specific ones later?

[cbeuw]

This seems like a deliberate design choice:

rust/compiler/rustc_span/src/source_map.rs

Lines 1030 to 1044 in 689e847

	/// Applies any path prefix substitution as defined by the mapping.
	/// The return value is the remapped path and a boolean indicating whether
	/// the path was affected by the mapping.
	pub fn map_prefix(&self, path: PathBuf) -> (PathBuf, bool) {
	// NOTE: We are iterating over the mapping entries from last to first
	// because entries specified later on the command line should
	// take precedence.
	for &(ref from, ref to) in self.mapping.iter().rev() {
	if let Ok(rest) = path.strip_prefix(from) {
	return (to.join(rest), true);
	}
	}
	(path, false)
	}

.rev() has been there since when path remapping was first introduced back in 2017: 39ffea3

Indeed by simply removing .rev() it gives the same behaviour as clang/gcc

$ build/x86_64-unknown-linux-gnu/stage1/bin/rustc apple/banana/chaenomeles.rs --remap-path-prefix=apple/banana/=/first/ --remap-path-prefix=apple/=/second/
$ ./chaenomeles thread 'main' panicked at 'explicit panic', /first/chaenomeles.rs:1:12
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The problem here is that is this a bug or a feature? It is working as intended by design, but the design was unusual when compared against clang/gcc

[nagisa]

Yeah, I opened this issue basically to figure out an answer to the last question. The source you linked seems to suggest to me its intended and given that this behaviour is long-standing I doubt we are in a position to change it anyway.

Thank you for looking into it.