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 (Issue 2708: recursive_directory_iterator::recursion_pending() is incorrectly specified) 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