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

> 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>

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

> 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