Stabilize `-Zremap-path-scope`
# Stabilization report of `--remap-path-scope`
## Summary
RFC 3127 trim-paths aims to improve the current status of sanitizing paths emitted by the compiler via the `--remap-path-prefix=FROM=TO` command line flag, by offering a profile setting named `trim-paths` in Cargo to sanitize absolute paths introduced during compilation that may be embedded in the compiled binary executable or library.
As part of that RFC the compiler was asked to add the `--remap-path-scope` command-line flag to control the scoping of how paths get remapped in the resulting binary.
Tracking:
- https://github.com/rust-lang/rust/issues/111540
### What is stabilized
The rustc `--remap-path-scope` flag is being stabilized by this PR. It defines which scopes of paths should be remapped by `--remap-path-prefix`.
This flag accepts a comma-separated list of values and may be specified multiple times, in which case the scopes are aggregated together.
The valid scopes are:
- `macro` - apply remappings to the expansion of `std::file!()` macro. This is where paths in embedded panic messages come from
- `diagnostics` - apply remappings to printed compiler diagnostics
- `debuginfo` - apply remappings to debug informations
- `coverage` - apply remappings to coverage informations
- `object` - apply remappings to all paths in compiled executables or libraries, but not elsewhere. Currently an alias for `macro,coverage,debuginfo`.
- `all` (default) - an alias for all of the above, also equivalent to supplying only `--remap-path-prefix` without `--remap-path-scope`.
#### Example
```sh
# With `object` scope only the build outputs will be remapped, the diagnostics won't be remapped.
rustc --remap-path-prefix=$(PWD)=/remapped --remap-path-scope=object main.rs
```
### What isn't stabilized
None of the Cargo facility is being stabilized in this stabilization PR, only the `--remap-path-scope` flag in `rustc` is being stabilized.
## Design
### RFC history
- [RFC3127 - trim-paths](https://rust-lang.github.io/rfcs/3127-trim-paths.html)
### Answers to unresolved questions
> What questions were left unresolved by the RFC? How have they been answered? Link to any relevant lang decisions.
There are no unresolved questions regarding `--remap-path-scope`.
(The tracking issue list a bunch of unresolved questions but they are for `--remap-path-prefix` or the bigger picture `trim-paths` in Cargo and are not related the functionality provided by `--remap-path-scope`.)
### Post-RFC changes
The RFC described more scopes, in particularly regarding split debuginfo. Those scopes where removed after analysis by `michaelwoerister` of all the possible combinations in https://github.com/rust-lang/rust/issues/111540#issuecomment-1994010274.
### Nightly extensions
There are no nightly extensions.
### Doors closed
We are committing to having to having a flag that control which paths are being remapped based on a "scope".
## Feedback
### Call for testing
> Has a "call for testing" been done? If so, what feedback was received?
No call for testing has been done per se but feedback has been received on both the rust-lang/rust and rust-lang/cargo tracking issue.
The feedback was mainly related to deficiencies in *our best-effort* `--remap-path-prefix` implementation, in particular regarding linkers added paths, which does not change anything for `--remap-path-scope`.
### Nightly use
> Do any known nightly users use this feature? Counting instances of `#![feature(FEATURE_NAME)]` on GitHub with grep might be informative.
Except for Cargo unstable `trim-paths` there doesn't appear any committed use [on GitHub](https://github.com/search?q=%22--remap-path-scope%22+NOT+path%3A%2F%5Esrc%5C%2Fcargo%5C%2Fcore%5C%2Fcompiler%5C%2F%2F+NOT+path%3A%2F%5Etext%5C%2F%2F+NOT+path%3A%2F%5Erust%5C%2Fsrc%5C%2Fdoc%5C%2Funstable-book%5C%2Fsrc%5C%2Fcompiler-flags%5C%2F%2F+NOT+path%3A%2F%5Esrc%5C%2Fdoc%5C%2Funstable-book%5C%2Fsrc%5C%2Fcompiler-flags%5C%2F%2F+NOT+path%3A%2F%5Ecollector%5C%2Fcompile-benchmarks%5C%2Fcargo-0%5C.87%5C.1%5C%2Fsrc%5C%2Fcargo%5C%2Fcore%5C%2Fcompiler%5C%2F%2F&type=code).
## Implementation
### Major parts
- b3f8586fb1/compiler/rustc_session/src/config.rs (L1373-L1384)
- b3f8586fb1/compiler/rustc_session/src/session.rs (L1526)
- b3f8586fb1/compiler/rustc_span/src/lib.rs (L352-L372)
### Coverage
- [`tests/run-make/split-debuginfo/rmake.rs`](9725c4baac/tests/run-make/split-debuginfo/rmake.rs (L7))
- [`tests/ui/errors/remap-path-prefix.rs`](9725c4baac/tests/ui/errors/remap-path-prefix.rs (L4))
- [`tests/ui/errors/remap-path-prefix-macro.rs`](9725c4baac/tests/ui/errors/remap-path-prefix-macro.rs (L1-L4))
- [`tests/run-make/remap-path-prefix-dwarf/rmake.rs
`](9725c4baac/tests/run-make/remap-path-prefix-dwarf/rmake.rs)
- [`tests/run-make/remap-path-prefix/rmake.rs`](9725c4baac/tests/run-make/remap-path-prefix/rmake.rs)
- [`tests/ui/errors/remap-path-prefix-diagnostics.rs`](9725c4baac/tests/ui/errors/remap-path-prefix-diagnostics.rs)
### Outstanding bugs
> What outstanding bugs involve this feature? List them. Should any block the stabilization? Discuss why or why not.
There are no outstanding bugs regarding `--remap-path-scope`.
### Outstanding FIXMEs
> What FIXMEs are still in the code for that feature and why is it OK to leave them there?
There are no FIXME regarding `--remap-path-scope` in it-self.
### Tool changes
> What changes must be made to our other tools to support this feature. Has this work been done? Link to any relevant PRs and issues.
- rustdoc (both JSON, HTML and doctest)
- `rustdoc` has support for `--remap-path-prefix`, it should probably also get support for `--remap-path-scope`, although rustdoc maybe want to adapt the scopes for it's use (replace `debuginfo` with `documentation` for example).
## History
> List issues and PRs that are important for understanding how we got here.
- https://github.com/rust-lang/rust/pull/115214
- https://github.com/rust-lang/rust/pull/122450
- https://github.com/rust-lang/rust/pull/139550
- https://github.com/rust-lang/rust/pull/140716
## Acknowledgments
> Summarize contributors to the feature by name for recognition and so that those people are notified about the stabilization. Does anyone who worked on this *not* think it should be stabilized right now? We'd like to hear about that if so.
- @cbeuw
- @michaelwoerister
- @weihanglo
- @Urgau
@rustbot labels +T-compiler +needs-fcp +F-trim-paths
r? @davidtwco
In the process also document that new `--remap-path-scope` scopes may be
added in the future, and that the `all` scope always represent all the
scopes.
Co-authored-by: David Wood <agile.lion3441@fuligin.ink>
Compute jump threading opportunities in a single pass
The current implementation of jump threading walks MIR CFG backwards from each `SwitchInt` terminator. This PR replaces this by a single postorder traversal of MIR. In theory, we could do a full fixpoint dataflow analysis, but this has low returns as we forbid threading through a loop header.
The second commit in this PR modifies the carried state to a lighter data structure. The current implementation uses some kind of `IndexVec<ValueIndex, &[Condition]>`. This is needlessly heavy, as the state rarely ever carries more than a few `Condition`s. The first commit replaces this state with a simpler `&[Condition]`, and puts the corresponding `ValueIndex` inside `Condition`.
The three later commits are perf tweaks.
The sixth commit is the main change. Instead of carrying the goto target inside the condition, we maintain a set of conditions associated with each block, and their consequences in following blocks. Think: if this condition is fulfilled in this block, then that condition is fulfilled in that block. This makes the threading algorithm much easier to implement, without the extra bookkeeping of `ThreadingOpportunity` we had.
Later commits modify that algorithm to shrink the set of duplicated blocks. By propagating fulfilled conditions down the CFG, and trimming costly threads.
pub async fn impl is monomorphized when func itself is monomorphized
Implentation coroutine (`func::{closure#0}`) is monomorphized, when func itself is monomorphized.
Currently, when `pub async fn foo(..)` is exported from lib and used in several dependent crates, only 'header' function is monomorphized in the defining crate. 'header' function, returning coroutine object, is monomorphized, but the coroutine's poll function (which actually implements all the logic for the function) is not. In such situation, `func::{closure#0}` will be monomorphized in every dependency.
This PR adds monomorphization for `func::{closure#0}` (coroutine poll function), when func itself is monomorphized.
Simple test with one lib async function and ten dependent crates (executable) that use the function, shows 5-7% compilation time improvement (single-threaded).
The bug was triggered by a particular usage of the `?` try operator in a
proc-macro expansion.
Thanks to lqd for the minimization.
Co-authored-by: Rémy Rakic <remy.rakic+github@gmail.com>
This case can't actually happen yet (other than via a testing flag), because
currently all of a function's spans must belong to the same file and expansion.
But this will be an important edge case when adding expansion region support.
This is a way to shrink call spans that doesn't involve mixing different spans,
and avoids overlap with argument spans.
This patch also removes some low-value comments that were causing rustfmt to
ignore the match arms.
This test is intended to demonstrate that a particular macro-argument span
doesn't get lost during span-refinement, but it turns out that span-extraction
currently doesn't yield any MIR spans for this position.
This patch therefore tweaks the test to add a function call in that position,
so that it still remains relevant to span refinement.
When preparing a function's coverage counters and metadata during codegen, any
part of the original coverage graph that was removed by MIR optimizations can
be treated as having an execution count of zero.
Somewhat counter-intuitively, if we give those unreachable nodes a _higher_
priority for receiving physical counters (instead of counter expressions), that
ends up reducing the total number of physical counters needed.
This works because if a node is unreachable, we don't actually create a
physical counter for it. Instead that node gets a fixed zero counter, and any
other node that would have relied on that physical counter in its counter
expression can just ignore that term completely.
coverage: Store coverage source regions as `Span` until codegen (take 2)
This is an attempt to re-land #133418:
> Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass.
> This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as Span instead.
> In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because Span is smaller than 4x u32.
That PR was reverted by #133608, because in some circumstances not covered by our test suite we were emitting coverage metadata that was causing `llvm-cov` to exit with an error (#133606).
---
The implementation here is *mostly* the same, but adapted for subsequent changes in the relevant code (e.g. #134163).
I believe that the changes in #134163 should be sufficient to prevent the problem that required the original PR to be reverted. But I haven't been able to reproduce the original breakage in a regression test, and the `llvm-cov` error message is extremely unhelpful, so I can't completely rule out the possibility of this breaking again.
r? jieyouxu (reviewer of the original PR)
