Following snippets will fail to format on windows.
#[path = "../mod_b.rs"]
mod b;
rustfmt-nightly will complain
error: couldn't read "\\?md5-5aa329475a4b12f58a4dc73b90430cffC:\src\../mod_b.rs": The filename, directory name, or volume label syntax is incorrect. (os error 123)
That's because rustfmt needs to canonicalize the source file paths first to be able to compare with file_lines configuration later. It works fine on linux. But on windows, canonicalize will return a UNC path, which doesn't accept relative join any more.
/cc rust-lang/rust#42869
Do you know how we should fix this? I feel like there must be some way to get a canonical path that will work on Windows.
After a post on reddit to encourage people to try out rustfmt in anticipation of a 1.0 release, I hit the same problem. Is this a blocking issue for a 1.0 release?
I'm still seeing this issue :/
I'm hitting this issue for coreutils (uutils/rust.coreutils) while attempting to add additional CI.
cc: @rivy
IIUC we need an equivalent to std::filesystem::absolute from C++17.
FWIW I just tested the std::filesystem::absolute under
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) (Ubuntu 18.04)cl.exe 19.20.27508.1 (MSVC v142, Windows 10.0.17763)and paths like /home/xanewok/../xanewok and \\?\C:\Users\Xanewok\t\..\t were not modified - this was only done by std::filesystem::canonical.
I'd also like to mention that std::fs::canonicalize seems to be wrong as it can't handle normalizing UNC paths with relative components (throws an error), while it's definitely possible in Windows (e.g. File Explorer can access such paths correctly). For Windows we're calling GetFinalPathNameByHandleW whereas we might want to explore calling PathCanonicalizeW instead, before passing the function later on.
I'd also like to mention that std::fs::canonicalize seems to be wrong as it can't handle normalizing UNC paths with relative components (throws an error), while it's definitely possible in Windows (e.g. File Explorer can access such paths correctly).
@Xanewok If possible, could you open an issue on the rust repo about this ? I believe you'd explain what is wrong better than me! Thanks
It seems a bunch of work is underway to tackle this:
Closed via #4131.
Most helpful comment
It seems a bunch of work is underway to tackle this: