# compiler-team#516: path santisation changes

https://github.com/rust-lang/rfcs/pull/3127

https://github.com/rust-lang/rfcs/blob/6e45014b20aac5c29ae34a41ffce8c768814fd60/text/3127-trim-paths.md

## Topics Discussed

### need remap for debuggers

> [name=bjorn3] https://github.com/rust-lang/rfcs/pull/3127#discussion_r882880626
> > The precompiled standard library libraries would use the virtual prefix even if rust-src is installed, so you have to add the remap for debuggers either way.

> mw: [SourceLink](https://github.com/dotnet/sourcelink) might interesting to look at for this. Which debuggers support it? Is this relevant for this RFC?

### Is de-mapping `sysroot` even possible to implement?

mw: See https://github.com/rust-lang/rfcs/pull/3127#pullrequestreview-1010498273

### (skipped) this is good for usability too, right?

pnkfelix: in addition to "privacy" and "build reproducibilty", I can imagine this is also useful just to make output nicer. Most people care about the *tail* of these paths, not the start of it.

> [name=bjorn3] For workspace members only the tail is shown already.
> ```rust
> fn main() {
> panic!();
> }
> ```
>
> ```
> thread 'main' panicked at 'explicit panic', src/main.rs:2:5
> stack backtrace:
> [...]
> 3: playground::main
> at ./src/main.rs:2:5
> [...]
> ```

### Set of scopes

pnkfelix: The set of valid scopes should not be considered fixed for all time here, right? I can imagine we would want to extend it in the future, and also perhaps remove items, maybe.

### `include!()` question

wesleywiser:

> Path introduced by include!() will be remapped, given that the included file is under the current working directory or a dependency package.

The path provided to `include!()` doesn't appear in the output binary (except perhaps via debuginfo?) so it's not clear to me why we need to remap the path passed to `include!()`.

> [name=bjorn3] It is contained in `Span` and thus ends up in the debuginfo/`file!()` output.

> [name=wesleywiser] Gotcha. Is this just about adjusting the spans after expanding `include!()` or do we have to adjust the path to `include!()` itself? I'm concerned about breaking code that works without `trim-paths`.

### `file!` breakage

pnkfelix: I'm a little concerned about the potential for this. 1. How likely are we to be able to detect such breakage via `crater` runs? 2. Should we think harder about ways to avoid it? E.g. by adding an optional parameter to `file!` that would control whether it respects the remapping or not?

### (skipped) can/should remap differ per-scope?

pnkfelix: (never mind, I failed to read all the way to the end before posting this.)

pnkfelix: I *infer* from the text that the remapping itself is specified in one place, and the set of scopes is specified in a different place, and you *cannot* ask for one remapping for one scope and a different remapping for a different scope. 1. Is this inference correct? 2. If it is correct, is there a scenario where one might *want* such per-scope specification of the remapping?

* Oh, that is listed in Future Possibilities

### system tools may introduce absolute paths

wesleywiser: More of a nit than anything but we might want to note that system tools such as the linker *could* introduce absolute paths into, for example, debuginfo during processing. Thus, this is a best-effort attempt on our part to remove certain paths from the final binary.

## Discussion Topics / Questions Queue

### planned `sysroot` remapping

pnkfelix: is the planned sysroot remapping, i.e.
> Only the virtual name is ever emitted for metadata or codegen. We want to change this behaviour such that, when rust-src source files can be discovered, the virtual path is discarded and therefore the local path will be embedded, unless there is a --remap-path-prefix that causes this local path to be remapped in the usual way.
>
is the above potentially a "breaking change" that may concern us? It seems possible that some people will prefer the current behavior there, and so at the very least we'll want to advertise how to reusethe remapping flags to get back the old behavior.