Use "expect" instead of "output" for generating "proximate_expected".
pass the arguments to PathEq in the same order as above.
Details
- Reviewers
curdeius • Quuxplusone - Group Reviewers
Restricted Project - Commits
- rG4d571cf4e99e: [libcxx] [test] Clarify and improve consistency in…
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/test/std/input.output/filesystems/class.path/path.member/path.gen/lexically_relative_and_proximate.pass.cpp | ||
---|---|---|
90 | Please name the variable proximate_expect instead of proximate_expected; or else name the variable and field above expected instead of expect. But they should be consistent with each other, one way or another. I had suggested using expect.empty() instead of expect.native().empty(), on the assumption that they do the same thing. I just checked the code in <filesystem> to be sure, and yeah, it sure looks like they do the same thing. Can you think of any reason the original programmer might have used expect.native().empty() here instead of the more natural expect.empty()? |
libcxx/test/std/input.output/filesystems/class.path/path.member/path.gen/lexically_relative_and_proximate.pass.cpp | ||
---|---|---|
90 | I can't see a good reason not to just use path::empty(), changing to use that. And renaming the variable. |
Please name the variable proximate_expect instead of proximate_expected; or else name the variable and field above expected instead of expect. But they should be consistent with each other, one way or another.
I had suggested using expect.empty() instead of expect.native().empty(), on the assumption that they do the same thing. I just checked the code in <filesystem> to be sure, and yeah, it sure looks like they do the same thing. Can you think of any reason the original programmer might have used expect.native().empty() here instead of the more natural expect.empty()?