Stabilize --remap-path-prefix in rustdoc

[Urgau]

View all comments

Stabilization report of --remap-path-prefix in rustdoc

Summary

rustc supports remapping source paths prefixes as a best effort in all compiler generated output, including compiler diagnostics, debugging information, macro expansions, documentation, doctests, etc.

This is useful for normalizing build products, for example, by removing the current directory out of the paths emitted into object files.

This stabilization stabilize the same flag used by rustc in rustdoc.

There are no tracking issue.

Stabilization was discussed at the last meeting, #t-rustdoc/meetings > 2026-04-13 @ 💬.

What is stabilized

The rustdoc --remap-path-prefix flag is being stabilized by this PR. (It's equivalent to rustc flag)

It permits remapping (as a best effort) source path prefixes in all output, including diagnostics, debug information, macro expansions, generated documentation, etc.

It takes a value of the form FROM=TO where a path prefix equal to FROM is rewritten to the value TO.

Example

rustdoc src/lib.rs --remap-path-prefix="$PWD=/foo"

What isn't stabilized

Neither --remap-path-scope (soon to be added as unstable in rustdoc #155451) or the already unstable in rustc documentation scope are being stabilized or added here.

Design

Implementation history

• rustdoc: Add support for --remap-path-prefix #107099

Unresolved questions

There are no unresolved questions.

Post-implementation changes

The implementation has evolved with rustc, but no changes to the flag it-self have been made.

Nightly extensions

The documentation scope, which currently can only be set from rustc, as we need to add an equivalent to the --remap-path-scope flag, which is planned (EDIT: #155451), but not required, the current --remap-path-prefix defaults to the all scope, like rustc.

Doors closed

We are committing to having to having a flag that permits remapping paths. The compiler team already made the same commitment.

Feedback

Call for testing

No call for testing has been done.

Nightly use

Unable to determine. A GitHub search only seems to only reveals the rustc usage (over 6k though).

Rust-for-Linux is using the flag.

Implementation

Major parts

• rustdoc: Add support for --remap-path-prefix #107099
• Overhaul filename handling for cross-compiler consistency #149709
• Handle remapped paths correctly when generating "Source" links #150172
• Add a documentation remapping path scope for rustdoc usage #151589

Coverage

• tests/rustdoc-ui/remap-path-prefix-failed-doctest-output.rs
• tests/rustdoc-ui/remap-path-prefix-invalid-doctest.rs
• tests/rustdoc-ui/remap-path-prefix-macro.rs
• tests/rustdoc-ui/remap-path-prefix-passed-doctest-output.rs
• tests/rustdoc-ui/lints/remap-path-prefix-lint.rs
• tests/rustdoc-html/import-remapped-paths.rs
• tests/rustdoc-html/macro/external-macro-src.rs

Outstanding bugs

There are no outstanding bugs regarding --remap-path-prefix in rustdoc.

There are caveats and limitation in rustc, but they mostly concern generated object files, which we don't really have.

Outstanding FIXMEs

There are no FIXME regarding --remap-path-prefix.

Acknowledgments

• @edward-shen
• @Urgau

@rustbot labels +T-rustdoc +F-trim-paths
cc @ojeda (for Rust-for-Linux)
r? rustdoc

[GuillaumeGomez]

@rfcbot fcp merge rustdoc-internals

[rust-rfcbot]

Team member @GuillaumeGomez has proposed to merge this. The next step is review by the rest of the tagged team members:

• @GuillaumeGomez
• @Manishearth
• @Urgau
• @camelid
• @fmease
• @lolbinarycat
• @notriddle
• @yotamofek

Concerns:

• parity resolved by Stabilize --remap-path-prefix in rustdoc #155307 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[lolbinarycat]

there seems to be a bit of an issue in the description

The rustdoc --remap-path-scope flag is being stabilized by this PR. (It's equivalent to rustc flag)

Neither --remap-path-scope (soon to be added as unstable in rustdoc) or the already unstable in rustc documentation scope are being stabilized or added here.

[lolbinarycat]

@rfcbot resolved parity

resolved in #155485

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[Urgau]

@bors r=GuillaumeGomez

[rust-bors]

📌 Commit d3bdea1 has been approved by GuillaumeGomez

It is now in the queue for this repository.

[JonathanBrouwer]

@bors yield
Yielding to enclosing rollup

[rust-bors]

Auto build was cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/26254332428

The next pull request likely to be tested is #156808.

[rust-bors]

☀️ Test successful - CI
Approved by: GuillaumeGomez
Duration: 3h 33m 7s
Pushing 4d276d7 to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing e96c36b (parent) -> 4d276d7 (this PR)

Test differences

Show 5 test diffs

Stage 2

• [run-make] tests/run-make/compressed-debuginfo-zstd: ignore (ignored if LLVM wasn't build with zstd for ELF section compression or LLVM is not the default codegen backend) -> pass (J0)

Additionally, 4 doctest diffs were found. These are ignored, as they are noisy.

Job group index

• J0: x86_64-gnu-nopt

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 4d276d7fdba2a24c73dbca3027461bb202e83436 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-msvc-ext1: 1h 24m -> 2h 19m (+64.5%)
2. pr-check-1: 42m 29s -> 26m 22s (-37.9%)
3. i686-msvc-1: 2h 54m -> 1h 54m (-34.5%)
4. x86_64-gnu-nopt: 2h 42m -> 1h 50m (-32.0%)
5. x86_64-rust-for-linux: 1h 5m -> 45m 15s (-30.6%)
6. x86_64-gnu-tools: 1h 19m -> 56m 37s (-28.9%)
7. aarch64-apple: 2h 47m -> 3h 26m (+23.6%)
8. dist-powerpc64le-linux-musl: 1h 38m -> 1h 16m (-22.4%)
9. dist-loongarch64-linux: 1h 51m -> 1h 28m (-20.9%)
10. pr-check-2: 50m 8s -> 40m 16s (-19.7%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (4d276d7): comparison URL.

Overall result: ❌ regressions - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.7%, 0.7%]	1
Regressions ❌ (secondary)	0.4%	[0.4%, 0.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.7%, 0.7%]	1

Max RSS (memory usage)

Results (primary 2.0%, secondary 2.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	4.3%	[2.3%, 6.3%]	2
Regressions ❌ (secondary)	2.0%	[1.8%, 2.1%]	3
Improvements ✅ (primary)	-2.7%	[-2.7%, -2.7%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.0%	[-2.7%, 6.3%]	3

Cycles

Results (secondary 2.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 530.554s -> 511.788s (-3.54%)
Artifact size: 400.60 MiB -> 400.54 MiB (-0.01%)