Details
- Reviewers
• Quuxplusone - Group Reviewers
Restricted Project - Commits
- rGb6d87773feef: [libc++] LWG3171: implement operator<< for filesystem::directory_entry.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/include/__filesystem/directory_entry.h | ||
---|---|---|
26 | From what I've seen, other headers that implement operator<< include <iosfwd> -- at the very least, I couldn't find one that includes <ostream>. However, I'm not sure this is actually valid given that the code actually invokes a member function on the stream (operator<<) whereas <iosfwd> only contains a forward declaration of the class. | |
libcxx/test/std/input.output/filesystems/class.directory_entry/directory_entry.io/directory_entry.io.pass.cpp | ||
15 | This test is largely copied from test/std/input.output/filesystems/class.path/path.nonmember/path.io.pass.cpp. | |
51 |
Please mention [LWG3171] in the commit subject line, and update Cxx2bIssues.csv. Otherwise, seems reasonable to me % comments.
libcxx/include/__filesystem/directory_entry.h | ||
---|---|---|
26 | I believe it's technically OK, because operator<< is always a template: it's calling a member function on some basic_ostream<C, T>, but that's a dependent type, so the call doesn't need to be (can't be) checked beyond that. | |
libcxx/include/filesystem | ||
48–51 ↗ | (On Diff #397454) | The extra // comment here was the red flag for me; but actually I think this entire diff is unnecessary. This operator<< is specified inside the body of class directory_entry; the body of directory_entry is not shown here; therefore this operator<< needn't be shown here. |
libcxx/test/std/input.output/filesystems/class.directory_entry/directory_entry.io/directory_entry.io.pass.cpp | ||
51 | path.io.pass.cpp (c79795874adef) and ostream_joiner.op.assign.pass.cpp (e046bbdded2c6) seem to be the only places in the codebase where we bother with this kind of commented-out char{8,16,32}_t business. I'm not sure it's worth duplicating here... but, your example seems to indicate that libc++'s lack of support for stringstream<char16_t> is actually a bug? libstdc++ and MSVC support char16_t streams reasonably well AFAICT. So perhaps this should be filed as a bug against libc++, and then you can explicitly mention https://llvm.org/PRxxxxx both here and in those two other places? |
libcxx/include/filesystem | ||
---|---|---|
48–51 ↗ | (On Diff #397454) | I'd agree with this, unless we want to detail all of class directory_entry in the synopsis, which might not be a bad idea. No strong preference here -- I don't think we have consistency about this in the library (but we seem to consistently *not* detail the classes in this header). |
Thanks! The version is 14.0, right?
libcxx/include/__filesystem/directory_entry.h | ||
---|---|---|
26 | Thanks for the explanation, changed to <iosfwd>. | |
libcxx/test/std/input.output/filesystems/class.directory_entry/directory_entry.io/directory_entry.io.pass.cpp | ||
51 | Yes, I think it's a bug (it happens with all sized character types and even unsigned char). Created a GitHub issue and referenced it in comments. |
libcxx/docs/Status/Cxx2bIssues.csv | ||
---|---|---|
20 | ||
libcxx/test/std/experimental/iterator/ostream.joiner/ostream.joiner.ops/ostream_joiner.op.assign.pass.cpp | ||
93 | Please use https://llvm.org/PRxxxxx URLs. |
Address feedback
libcxx/docs/Status/Cxx2bIssues.csv | ||
---|---|---|
20 | Sorry about that! | |
libcxx/test/std/experimental/iterator/ostream.joiner/ostream.joiner.ops/ostream_joiner.op.assign.pass.cpp | ||
93 | Can you please elaborate a little? First of all, which patch do I use? IIUC, libc++ bugs are reported on GitHub, so I'm not sure which patch should be used here. Second, why is a link to a patch preferable to a link to a GitHub issue? |
LGTM except for my comment on the test, which is major.
libcxx/test/std/experimental/iterator/ostream.joiner/ostream.joiner.ops/ostream_joiner.op.assign.pass.cpp | ||
---|---|---|
93 | https://llvm.org/PR53119 . In LLVM jargon, "PR" stands for "problem report" (or some such). The benefit of llvm.org URLs over github.com URLs is that we control the former, so they're less likely to bit-rot ten years from now. | |
libcxx/test/std/input.output/filesystems/class.directory_entry/directory_entry.io/directory_entry.io.pass.cpp | ||
40 | Waaaaitaminute. This is <<ing a path, but aren't you supposed to be <<ing a directory_entry here? |
libcxx/test/std/input.output/filesystems/class.directory_entry/directory_entry.io/directory_entry.io.pass.cpp | ||
---|---|---|
40 | Thanks a lot! |
LGTM % comments; please wait for a second green light before landing.
libcxx/test/std/experimental/iterator/ostream.joiner/ostream.joiner.ops/ostream_joiner.op.assign.pass.cpp | ||
---|---|---|
93 | This hasn't been done yet. | |
libcxx/test/std/input.output/filesystems/class.directory_entry/directory_entry.io/directory_entry.io.pass.cpp | ||
37 | Consider const-qualifying (just to prove that operator<<'s operand is const-qualified), and prefer parens-init to brace-init for non-aggregates: const fs::directory_entry dir = fs::directory_entry(fs::path(input)); (I also think this is the only line that needs fs:: qualifiers, so if you adopt the above suggestion, you can remove lines 32-33 entirely.) |
libcxx/test/std/experimental/iterator/ostream.joiner/ostream.joiner.ops/ostream_joiner.op.assign.pass.cpp | ||
---|---|---|
93 | Sorry, I somehow missed this comment. Done now, and thanks for the explanation. |