[libcxx-commits] [libcxx] [libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (PR #71002)

[Nikolas Klauser via libcxx-commits]

philnik777 wrote:

> > > It's not about back-porting, it's an abi break in libc++18. when building user code with libc++17, `_LIBCPP_ABI_ENABLE_ADDITIONAL_IOSTREAM_EXPLICIT_INSTANTIATIONS_1` is not defined unless targeting `_LIBCPP_ABI_VERSION >= 2`, but libc++18 doesn't check `_LIBCPP_ABI_VERSION`, and there is no way to disable `extern template class _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS basic_ifstream<char>`. The break comes from https://reviews.llvm.org/D154796
> > 
> > 
> > It's not an ABI break. Programs compiled against older libc++ version still work just fine with the dylib from libc++18. Programs compiled against a newer version of libc++ assume that symbols are available that aren't in older dylibs, which makes it a matter of availability (i.e. back-porting), not ABI.
> 
> So how can I build with the libc++ and run on old systems? distribute apps with the latest libc++? AFAIK these changes don't break apple OSes, it's better to provide an option to not break linux too.

Distributing your own dylib is always an option, but may not be desirable. The way to make it work properly is to do the same thing as Apple does: Provide availability information. This has to be maintained of course, but it's the only way for us to know when to provide certain functionality. You'd basically have to
- add a flag like `-mubuntu-version-min` to clang which adds a `__UBUNTU_VERSION__` macro
- extend `[[clang::availability]]` to accept `ubuntu` as a platform and uses the flag to check whether something is available
- extend `__availability` with the corresponding availability requirements for ubuntu.

I'm pretty sure the only thing that has to be updated is the information in `__availability`. Anything else should be fine just sitting around.

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