Rustdoc: pages are being overwritten on the file systems with case-insensitive names
Not sure if we can work around the case-insensitivity but when generating docs for the identifiers with the same name, but different cases(well it is ok for Rust after all :)) Like: https://github.com/DoumanAsh/trace-macro/blob/master/src/lib.rs#L29 https://github.com/DoumanAsh/trace-macro/blob/master/src/lib.rs#L150
We will have only one page, instead of two. I suspect that the last generated page will overwrite the first one since from Win file-system point of view it will be the same file.(And NTFS is also case-insensitive?)
I'm not sure what would be a good work around for that. I suppose it would be good idea to track names to avoid such issues and if there are several identifiers with the same names(different case) it should warn and generate pages with some suffix(like [-num]). Or even no need to warn, after all docs will be generated successfully.
Rust stable 1.0
rustdoc 1.0.0 (a59de37e9 2015-05-13) (built 2015-05-14)
Win8 x64
cc me (and also, sigh)
If anyone wants to tackle this I'm happy to mentor, however, it won't be super-easy.
Nick Cameron at 2016-07-26 23:31:15
Triage: i'm not aware of any changes here, nor any plans to fix this any time soon
Steve Klabnik at 2018-10-31 14:42:15
One option would be to generate a disambiguation page whenever this problem is detected. That way inbound links will still work correctly, with the only downside that the user has to click an extra time.
Diggory Blake at 2020-12-01 18:24:32
I would edit the summary to make this clearer, but this affects:
- Windows (all vFAT, EXFAT, NTFS without FILE_FLAG_POSIX_SEMANTICS)
- MacOSX (HFS+ and APFS both default to case insensitivity and require a reformat to be case sensitive).
Robert Collins at 2021-03-16 21:04:19
Is this not the general problem of tying filenames directly to Rust identifiers? For example an easy way to break rustdoc on Windows is:
pub mod nul {}Chris Denton at 2021-03-19 10:58:43