[llvm-dev] [cfe-dev] Filesystem has Landed in Libc++

[Louis Dionne via llvm-dev]

> On Aug 10, 2018, at 13:28, Marshall Clow via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> 
> 
> On Thu, Jul 26, 2018 at 9:20 PM, Eric Fiselier via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> Hi All,
> 
> I recently committed <filesystem> to trunk. I wanted to bring attention to some quirks it currently has.
> 
> First, it's been put in a separate library, libc++fs, for now. Users are responsible for linking the library when they use filesystem.
> 
> Second, it should still not be considered ABI stable. Vendors should be aware of this before shipping it. Hopefully all the standard and implementation bugs can be resolved by the next release, and we can move it into the main dylib.
> 
> [I have had discussions with several people, and I'm attempting to summarize here]
> 
> Due to factors beyond our control, I do not believe that we can provide a version of std::filesystem and promise future ABI stability at this time.
> 
> More information:
> 
> * The features for caching directory information were added late in the C++17 cycle, and there have been some concerns about them.
> LWG issue #2708 (https://wg21.link/lwg2708 <https://wg21.link/lwg2708>) is one of them, and there are a couple of upcoming papers about the same part of the standard.
> 
> * The clock stuff being added in C++20 has already been discussed here.
> 
> 
> We can:
> 
> 1) Not ship std::filesystem, shipping only std::experimental::filesystem.
> I think that this is a disservice to our users; because people are asking for std::filesystem, and other vendors are providing it.
> Note: experimental::filesystem is *different* from std::filesystem, and they're only going to diverge further. In an ideal world, we would have two implementations; one for experimental::filesystem, and the other for std::filesystem, and they would behave differently (each according to their specification)
> 
> 2) Ship std::filesystem as it is, as part of libc++.dylib.
> I don't think that this is a viable option, given that we are pretty sure (certain) that ABI changes are coming down the pike.
> 
> 3) We can ship std::filesystem as a static library; marked as "not ABI stable"
> We can put it into the libc++ dylib once we’re confident that we can provide a stable ABI.

After talking to Marshall and Eric, I believe 3) is OK and I take back my objection to shipping a non-experimental filesystem in LLVM 7. The main reasons are:

- We’re forcing users to link manually with -lc++fs. This forces them to read the documentation, which contains a fat warning about ABI stability.
- This is what GCC and MS have done — it’s easier if we stay aligned with them.
- Since we’re shipping c++fs as a static library, the only potential problem is that users will use ABI-unstable types in their own ABIs. We’re not going to break the symbols exported from libc++.dylib at all.
- Filesystem is in an inline namespace __fs, so we can decide to bump that inline namespace if we break the ABI. This will cause users that may have leaked filesystem types in their ABIs to get clear link errors when we change the ABI.

So I think 3), which is the status quo, is fine.

Louis

> 
> Note: libstdc++ has done exactly this.
> See https://www.reddit.com/r/cpp/comments/789g99/gcc_lands_support_for_c_filesystem_ts/ <https://www.reddit.com/r/cpp/comments/789g99/gcc_lands_support_for_c_filesystem_ts/> for a discussion of this approach.
> 
> People can use std::filesystem, and include the object code it in their executables, and when the ABI changes, they will be affected at build time, not at run time. The downside is that they will have to re-build to get bug fixes.
> 
> -- Marshall
> 
> P.S. I admit that this is not the best of all possible worlds.
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180810/f778009a/attachment.html>