Add os::windows::ffi::OsStrExt::system_cmp and system_eq

[CDirkx]

Adds two methods to the extension trait OsStrExt on Windows for dealing with case-insensitive strings: system_cmp and system_eq. These methods use the system case-insensitive implementation CompareStringOrdinal with bIgnoreCase, which differs from a pure Unicode case-insensitive comparison (which is why I explicitly named these methods system_ instead of something like case_insensitive_).

These methods are the correct way for comparing environment variable keys, registry keys, resource handle names etc. on Windows, e.g. "Path" and "PATH" are treated the same by the system and should compare equal.

This is the minimal way I thought of for enabling the use of Windows specific case-insensitive comparisons. There are several ways this could be extended further if necessary:

• Also have extension traits with system_cmp and system_eq for Path, [u8]?, [u16]? (This is not the correct way to compare paths: Tracking Issue for windows_case_insensitive #86007 (comment))
• Introduce a trait SystemOrd and SystemEq in std::os::windows.
• Introduce a wrapper type like num::Wrapping for OsStr that overrides the Ord and Eq implementation.

Inspired by #85270

Tracking issue: #86007

[rust-highfive]

r? @kennytm

(rust-highfive has picked a reviewer for you, use r? to override)

[CDirkx]

As per #86007 (comment) this might still not be the correct way for dealing with file paths. What should we say about this in the documentation?

[ChrisDenton]

Personally, I'm uncertain. Perhaps remove "file paths" from that list but then add a note that file paths may have different rules? I think system_cmp could still perhaps be useful as a heuristic (i.e. these two paths may be equal) so long as it isn't relied upon for file paths.

But I don't think there's any OS support for comparing file paths other than opening both files and seeing if they point to the same file. Which obviously can't be done if one of the paths doesn't yet exist (or they can't be opened for some other reason). I mean, system_cmp may work for file paths most of the time but when it doesn't it could be a footgun. Or at least surprising when two "equal" paths point to different files.

[CDirkx]

Yeah comparing file paths is more complex, also due to the possibility of relative paths, verbatim paths, UNC prefixes, symlinks, etc; there are many ways in which two different paths can be equivalent.

It seems more appropriate to find a separate correct solution for that, so I'll leave it out of the documentation in this PR.

[nagisa]

Also have extension traits with system_cmp and system_eq for Path, [u8]?, [u16]?

I believe that the case sensitivity is a filesystem (and nowadays, per-directory) property, rather than a OS-specified one, so naming them system_* would likely be quite confusing. If adding comparison methods like these for Path is a goal, I think it is worthwhile to prototype an addition now (in order to see if it is at all possible to implement anything reasonable) and if so, consider if system_* naming is good for the functionality included in this PR.

[CDirkx]

Yes for paths it seems better to offer a fs function similar to the C++ std::filesystem::equivalent, which opens the two paths and compares the results of stat. Therefore I think it would be best to only add these methods to OsStr, and when such an equivalent function exist in Rust explicitly call it out as the correct way for comparing file paths (Currently the proposed docs in this PR have: "This is the correct way to compare various strings on Windows (...) Note that this does not include file names or paths; those can be case-sensitive depending on the system, file system or directory settings").

[camelid]

I think you're missing a closing ```?

[JohnCSimon]

@CDirkx can you address the comment from Camelid

[JohnCSimon]

ping from triage:
@CDirkx

returning to author to address comments
thanks.

[bors]

☔ The latest upstream changes (presumably #89174) made this pull request unmergeable. Please resolve the merge conflicts.

[JohnCSimon]

@CDirkx
I'm closing this PR is inactive, please feel free to reopen when you're ready to continue.
@rustbot label: +S-inactive