[libcxx-commits] [libcxx] [libcxx] Cache file attributes during directory iteration. (PR #93316)

[Louis Dionne via libcxx-commits]

ldionne wrote:

Ahhhh, I understand what's going on. I think that as-is, this change is actually an ABI break but there should be a way to deploy it.

Basically, `libcxx/include/__filesystem/directory_entry.h` now relies on the fact that the shared library is filling up all the right attributes within a cached entry. But if you run against an older shared library that doesn't contain the changes in this PR, the cached entries created by that shared lib will not be fully populated. This scenario can happen if you e.g. compile an application against the latest libc++ headers and then try to deploy it on an older operating system that uses a previously-compiled libc++ shared library. That's what we call the "back-deployment use case" and we typically test it on macOS, which is what the CI failures are about.

The typical way of making changes of this kind is to guard the new code you want to introduce behind a macro that basically says "I want promise I am not deploying to a system that doesn't have the changes in this PR". You can look at how e.g. `_LIBCPP_AVAILABILITY_HAS_TZDB` handles it in `__configuration/availability.h` for examples, but basically you'd need to guard your changes with something like

```c++
#if _LIBCPP_AVAILABILITY_HAS_FULLY_POPULATED_CACHED_ENTRY
...
#endif
```

where, in `__configuration/availability.h`, you define:

```c++
#define _LIBCPP_AVAILABILITY_HAS_FULLY_POPULATED_CACHED_ENTRY _LIBCPP_INTRODUCED_IN_LLVM_19
```

You might also want to slightly reorganize the code changes in your PR to avoid making it a maze of `#ifdef`s.

https://github.com/llvm/llvm-project/pull/93316