Heuristically undo path prefix mappings.

[TimNN]

Because the compiler produces better diagnostics if it can find the source of (potentially remapped) dependencies.

The new test fails without the other changes in this PR. Let me know if you have better suggestions for the test directory. I moved the existing remapping test to be in the same location as the new one.

Some more context: I'm exploring running UI tests with remapped paths by default in #105924 and this was one of the issues discovered.

This may also be useful in the context of rust-lang/rfcs#3127 ("New rustc and Cargo options to allow path sanitisation by default").

[TimNN]

Oh, I just remembered that I should probably run this through the Windows CI to ensure there are no Windows specific path handling issues.

Feel free to review already but please hold off on approving while I temporarily modify the CI config.

Also: r? compiler

[TimNN]

Windows CI looks good, I've removed the CI changes again.

[oli-obk]

How will this affect

rust/src/tools/compiletest/src/runtest.rs

Lines 1933 to 1938 in d12412c

	// Hide libstd sources from ui tests to make sure we generate the stderr
	// output that users will see.
	// Without this, we may be producing good diagnostics in-tree but users
	// will not see half the information.
	rustc.arg("-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX");
	rustc.arg("-Ztranslate-remapped-path-to-local-path=no");

if applied to the entire test suite? We do want to hide libstd/libcore sources from ui tests, so that we actually test the diagnostics shown to users, instead of only diagnostics shown to users who installed the rustc-src rustup component

[TimNN]

I don't believe the flags will be affected at all. AFAICT neither flag affects the contents of the FilePathMappings and thus their behavior won't be influenced by this patch at all.

Both flags seem to operate on a lower level (fiddling with the file paths when decoding metadata).

[oli-obk]

Thanks, that makes sense

@bors r+

[bors]

📌 Commit 869df76 has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit 869df76 with merge 4817259...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 4817259 to master...

[rust-timer]

Finished benchmarking commit (4817259): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.7%, 0.8%]	3
Regressions ❌ (secondary)	0.4%	[0.3%, 0.6%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.7%, 0.8%]	3

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	6.8%	[6.8%, 6.8%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.9%	[-2.9%, -2.9%]	2
All ❌✅ (primary)	-	-	0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.6%	[1.5%, 4.5%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

[TimNN]

Is there any straightforward way to see where the slowdown is coming from? I clicked through some of the pages in the report and the self profiles weren't really helpful.

Is this significant enough to warrant some kind of follow up?

[rylev]

I could certainly see going either way on whether this is significant enough to look into - definitely not worth a huge investigation but might be worth some small peek.

Looking at the callgrind-diff output for the primary regression, I see FromGenerator<<rustc_metadata::creader::CrateMetadataRef>::get_module_children with the biggest increase in all regressions, but I don't see how this code would change how many times we're calling into that function.

[pnkfelix]

From the graph, I think this is just noise

@rustbot label: perf-regression-triaged