This follows up on D89679, where @ldionne suggested we should remove
these nonstandard functions altogether. In practice, one of them is
unused and the other one is only used in one single test. (D89679
marks those calls as libcxx specific to make the test runnable with
other C++ standard library implementations.)
Details
- Reviewers
ldionne - Group Reviewers
Restricted Project - Commits
- rG341cc1b41132: [libcxx] Remove nonstandard _FilesystemClock::{to,from}_time_t
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This revision removes the only available methods to convert std::chrono::file_time_type to/from anything else.
The standard says std::chrono::file_time_type::clock should have methods: to_sys() and from_sys() to convert to/from std::chrono::system_time.
Is it possible to revert this change until the standard methods are implemented?
https://reviews.llvm.org/D113430 landed now, which should have implemented the standard methods instead.
That doesn't help, since the standard methods are only available since C++20, while the ones removed here were available for earlier standards. There is code out there, which already relies on these non-standard functions and it's going to be broken by this change without a reasonable alternative (migrating the code to C++20 is not a real alternative). While I understand the desire to strictly follow the standard, it's also not nice to break existing code that relied on these features without a transition period. Can we have this reverted to give folks time to migrate code? To prevent backslide, these non-standard API fragments could be placed under an #ifdef and accompanied by a compiler warning.
That sounds reasonable to me, but @ldionne has the final say on the matter.
How do you handle this with other C++ libraries, do they provide to_sys/from_sys even before C++20, or do they use some other nonstandard method, or were you only using this setup on libc++?
The code in question only uses libc++.
One thing that jumps out to me is that these methods were not uglified, not in the implementor's namespace, so users could reasonably consider them to be stable. To me, that seems like a good argument for reverting.
Why is migrating to C++20 not a real alternative? Just curious.
I would suggest we do this:
- Add the methods back unless _LIBCPP_ENABLE_REMOVED_FILE_CLOCK_TIME_T_METHODS is defined.
- Update the release note to mention that folks can use that macro to re-enable the methods temporarily, but that the option will be removed in two releases so they should move to C++20.
Whoever is broken by this will see the breakage, then read the release notes, define _LIBCPP_ENABLE_REMOVED_FILE_CLOCK_TIME_T_METHODS, and make a note to move to C++20 before they are broken for good.
The plan above looks reasonable to me.
I looked a bit closer and found that performing conversion close to how the removed methods used to do this looks like an appropriate solution for our code: std::filesystem::file_time_type(std::chrono::duration<std::filesystem::file_time_type::rep>(time_t_time)) and std::time_t(std::chrono::duration_cast<std::chrono::duration<std::filesystem::file_time_type::rep>>(fs_time.time_since_epoch()).count()) seem to not rely on anything beyond C++17 standard. And while being more graceful when removing non-standard APIs still makes sense, we're likely not going to be blocked on this particular removal.