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

[Hans Wennborg via cfe-dev]

On Fri, Aug 10, 2018 at 7:51 PM, Louis Dionne via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>
>
> 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> 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) 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.

Just to double check: this means we don't need to do anything for the 7 branch?

Thanks,
Hans