This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] [test] Adjust separator form in fs.op.absolute for libc++ on windows
ClosedPublic

Authored by mstorsjo on Mar 8 2021, 1:14 PM.

Details

Summary

This test was previously tweaked in
321f696920630be1b3c93e2a8b965c624ddd646c to match the output of
of MS STL (except that the MS STL fails on the testcase with an
empty path).

libc++ doesn't produce paths with all normalized separators (and the
spec doesn't mandate it to either).

Tweak the test reference to match exactly what libc++ produces. If
testing with a non-libc++ library, do a relaxed comparison that allows
the separators to differ.

Diff Detail

Event Timeline

mstorsjo requested review of this revision.Mar 8 2021, 1:14 PM
mstorsjo created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptMar 8 2021, 1:14 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Quuxplusone added inline comments.
libcxx/test/std/input.output/filesystems/fs.op.funcs/fs.op.absolute/absolute.pass.cpp
53–54

I'm no expert on <filesystem>, but based purely on cppreference, I wouldn't trust path::operator== to do the right thing. It definitely does more than just "separator-agnostic comparison":
https://en.cppreference.com/w/cpp/filesystem/path/compare

I see no problem with D98109 (tightening up the output of absolute). It sounds like you're planning to abandon D98109 and keep the loosey-goosey output, which means the test code will need a "separator-agnostic comparison" function. Instead of using ==, how about making a helper function like PathEq that simply calls .make_preferred() on both paths and then strcmps them? Then we know we're not relying on any other weirdness introduced by path::operator==.

mstorsjo updated this revision to Diff 329212.Mar 8 2021, 10:06 PM

Added a helper for doing path equality checks ignoring separator style

curdeius accepted this revision as: curdeius.Mar 8 2021, 11:25 PM

I like Arthur's idea. LGTM.

Quuxplusone accepted this revision.Mar 9 2021, 6:50 AM

I still don't really understand what was wrong with D98109; but given that we're going this route, this new code is nice and clear. :)

This revision is now accepted and ready to land.Mar 9 2021, 6:50 AM