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

[Louis Dionne via llvm-dev]

> On Aug 27, 2018, at 05:49, Hans Wennborg <hans at chromium.org> wrote:
> 
> 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?

That is my understanding.

Louis

> 
> Thanks,
> Hans