[PATCH] D45942: [Support/Path] Make handling of paths like "///" consistent

[Pavel Labath via Phabricator via llvm-commits]

labath created this revision.
labath added reviewers: zturner, espindola.

Various path functions were not treating paths consisting of slashes
alone consistently. For example, the iterator-based accessors decomposed the
path "///" into two elements: "/" and ".". This is not too bad, but it
is different from the behavior specified by posix:

  A pathname that contains ***at least one non-slash character*** and that
  ends with one or more trailing slashes shall be resolved as if a single
  dot character ( '.' ) were appended to the pathname.

More importantly, this was different from how we treated the same path
in the filename+parent_path functions, which decomposed this path into
"." and "". This was completely wrong as it lost the information that
this was an absolute path which referred to the root directory.

This patch fixes this behavior by making sure all functions treat paths
consisting of (back)slashes alone the same way as "/". I.e., the
iterator-based functions will just report one component ("/"), and the
filename+parent_path will decompose them into "/" and "".

A slightly controversial topic here may be the treatment of "//". Posix
says that paths beginning with "//" may have special meaning and indeed
we have code which parses paths like "//net/foo/bar" specially. However,
as we were already not being consistent in parsing the "//" string
alone, and any special parsing for it would complicate the code further,
I chose to treat it the same way as longer sequences of slashes (which
are guaranteed to be the same as "/").

Another slight change of behavior is in the parsing of paths like
"//net//". Previously the last component of this path was ".". However,
as in our parsing the "//net" part in this path was the same as the
"drive" part in "c:\" and the next slash was the "root directory", it
made sense to treat "//net//" the same way as "//net/" (i.e., not to add
the extra "." component at the end).


Repository:
  rL LLVM

https://reviews.llvm.org/D45942

Files:
  lib/Support/Path.cpp
  unittests/Support/Path.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D45942.143518.patch
Type: text/x-patch
Size: 6074 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180423/b77ced2c/attachment.bin>