[PATCH] D87732: [Support] Provide sys::path::guess_style

[Petr Hosek via Phabricator via llvm-commits]

phosek added a comment.

In D87732#2275943 <https://reviews.llvm.org/D87732#2275943>, @jhenderson wrote:

> I'm not convinced this is really correct. After all, a path with mixed separators (e.g. '/my/path\to\foo') could be a Windows path rooted at the current drive. This mixed style can sometimes happen when things get concatenated together, so I don't think it's compeletely unreasonable.
>
> I'm also concerned that if we guess wrong, the behaviour will end up breaking. For example, if the path were a Windows path "/my/path\../to/foo", I'd expect a remove_dots call (without worrying about slash normalisation) to result in "/my/to/foo", but if the code is using Posix style, will it actually result in the path being left unchanged?
>
> I can think of two competing alternatives:
>
> 1. add an option to `remove_dots` to not do the separator canonicalization. I'm not sure whether this can be done unambiguously however - which separator should be removed when a directory is removed due to dots? The one before the removed parts? After them?
> 2. change all '\' to '/' unconditionally. However, this might break Linux paths with '\' in.

None of these solutions is perfect and I'm not even sure if there's one. Even if we improve `remove_dots`, there's still the existing issue with `sys::path::append`: which separator should we use when combining compilation dir, include dir and the file name.

Maybe we should instead update Clang to do the normalization when generating debug info and always use `/`, and then always use `/` unconditionally when combining paths on the consumer side (but don't do any normalization)?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87732/new/

https://reviews.llvm.org/D87732