Windows paths should not be prefixed with \\?\ when displayed

[Zoxc]

That just turns this already confusing error into an insult:

kernel\std\std.rs:17:1: 17:46 error: found possibly newer version of crate `core` which `core_collections` depends on [E0460]
kernel\std\std.rs:17 extern crate collections as core_collections;
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kernel\std\std.rs:17:1: 17:46 note: perhaps this crate needs to be recompiled?
kernel\std\std.rs:17 extern crate collections as core_collections;
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kernel\std\std.rs:17:1: 17:46 note: crate `core` path #1: \\?\B:\Programmering\SandboxOS\AveryRust\build\sysroot\lib\rustlib\x86_64-avery-kernel\lib\libcore.rlib
kernel\std\std.rs:17:1: 17:46 note: crate `core_collections` path #1: \\?\B:\Programmering\SandboxOS\AveryRust\build\sysroot\lib\rustlib\x86_64-avery-kernel\lib\libcollections.rlib

[retep998]

Rust is canonicalizing the path in order to get a full path, and the method it uses to do so results in a verbatim path that starts with the prefix \\?\. It is very much a valid path in that format and doesn't seem like a bug to me.

[hanna-kruppe]

Even if the path is correct, it seems like a usability hazard. Most people, even most programmers, have never seen this path format and would be unnecessarily distracted by it. Is there an easy, robust way to omit the prefix when it's not needed? AIUI \\?\ is redundant when the path is reasonably short and refers to a local file (rather than something on a network share).

[Zoxc]

You can always remove the prefix. It only needs to be there when calling WinAPI file functions (which is not the case here).

[nagisa]

You can always remove the prefix.

UNC\server\share\something is not the same path as \\?\UNC\server\share\something.

[Zoxc]

@nagisa For UNC paths only ?\ should be removed

[steveklabnik]

Triage: are there reproduction instructions for getting this exact error? I have a feeling that this is still the same today, but it would be nice to verify.

[Zoxc]

Just build the compiler enough times and you'll run into it. Just got:

error[E0460]: found possibly newer version of crate `std` which `synstructure` depends onialize, cc, winapi, crossbeam-epoch, serialize, polonius-engine, chalk-engine, rand_pcg, flate2, rand_chacha, rustc_apfloat, rustc_macros
 --> src\librustc_macros\src\lib.rs:6:5
  |
6 | use synstructure::decl_derive;
  |     ^^^^^^^^^^^^
  |
  = note: perhaps that crate needs to be recompiled?
  = note: the following crate versions were found:
          crate `std`: \\?\B:\dev\rust\rustc-perf\build\x86_64-pc-windows-msvc\stage1\lib\rustlib\x86_64-pc-windows-msvc\lib\libstd-ea36dd8c264badab.rlib
          crate `std`: \\?\B:\dev\rust\rustc-perf\build\x86_64-pc-windows-msvc\stage1\lib\rustlib\x86_64-pc-windows-msvc\lib\std-ea36dd8c264badab.dll
          crate `synstructure`: \\?\B:\dev\rust\rustc-perf\build\x86_64-pc-windows-msvc\stage1-rustc\release\deps\libsynstructure-64a0f32c5840d1f1.rlib

[retep998]

\\?\ paths would never show up in rustc normally if #59117 were ever implemented.

[ChrisDenton]

I tried implementing this in the PR linked above. However, I think there are simply too many edge cases that make this far more complex than I'm comfortable with when just using path.display().

One potential way forward for the standard library would be to have some kind of display configuration for paths. E.g. it could configure things like how to handle unprintable characters or whether to convert verbatim paths. But I've not really thought about how workable this is.

Otherwise there are third party crates that people can use.