[Clang] Add `-funstable` flag to enable unstable and experimental features

[egorzhdan]

Summary

This new flag enables __has_feature(cxx_unstable) that would replace libc++ macros for individual unstable/experimental features, e.g. _LIBCPP_HAS_NO_INCOMPLETE_RANGES or _LIBCPP_HAS_NO_INCOMPLETE_FORMAT.

This would make it easier and more convenient to opt-in into all libc++ unstable features at once.

[zoecarver]

This looks great, thanks Egor!

[ldionne]

Oops, this seems to have happened while I was on vacation. I wanted to have a wider discussion here before shipping the patch. Let's have it now and we can make post-commit changes depending on where the discussion leads.

So, what we're trying to achieve here is to provide a user-controlled flag to enable things that are not "production ready". This includes:

• TSes (since we remove them after shipping the "real thing" for two releases)
• Standardized features that we implement only in part (for example <ranges>, where we don't yet have a fully coherent thing to ship, so we'd rather not pretend that we ship it in a stable way yet)
• Standardized features that we know for a fact are about to be broken by the Standard itself (this happened with <ranges> and <format> recently)

The problem this solves is that in the current state of things, we end up simply not shipping those features at all by fear that users are going to start depending on them, and then we'll break them. We want to be able to ship these features without actually committing to their stability.

We considered a few alternative directions for this patch, which we rejected:

• -fexperimental: We decided not to go with this because we wanted to convey the fact that said features were unstable, and hence dangerous to use in production code
• -std=c++latest: This would be close to what MSVC does. We decided not to go down this route because we felt like it didn't properly convey the notion of instability. Instead, we felt that -std=c++latest could/should be a simple alias for whatever the latest known standard is (which is not part of this patch).

Does anyone have thoughts?

clang/include/clang/Basic/LangOptions.def

153

The documentation of this option should be way more beefy. Something like:

Enable unstable and experimental language and library features.

This option enables various language and library features that are either experimental (also known as TSes), or have been standardized but are not stable yet. This option should not be used in production code, since neither ABI nor API stability are guaranteed.

We should also provide documentation inside clang/docs/ClangCommandLineReference.rst.

clang/lib/Driver/ToolChains/Clang.cpp

5728

We should also be adding -lc++experimental if the standard library is libc++.

[Mordante]

Thanks for implementing this @egorzhdan! Thanks @ldionne for the notification.

-funstable is an option that controls multiple flags therefore I think it would be good to have a separate flag to opt-in for unstable/incomplete libc++ features. That makes it easier to _only_ opt-in to these features. Then -funstable can also enable that flag. Maybe -funstable-libc++ and adding a feature libcxx_unstable that we can use in libc++ to detect that the flag was set.

clang/include/clang/Basic/LangOptions.def

153

+1

clang/lib/Driver/ToolChains/Clang.cpp

5727

Is this option still useful? In LLVM 14 the <coroutine> header is no longer experimental. The experimental header will soon be removed.

[egorzhdan]

Apologies for landing this too quickly! I'll adjust this logic in a separate patch: https://reviews.llvm.org/D121141

In D120160#3352399, @Mordante wrote:

-funstable is an option that controls multiple flags therefore I think it would be good to have a separate flag to opt-in for unstable/incomplete libc++ features. That makes it easier to _only_ opt-in to these features.

@Mordante could you please elaborate a little bit, are you proposing a separate flag that would be equivalent to -Xcc -funstable (essentially to enable LangOpts.Unstable but not the rest of the flags) and have a different spelling to indicate that it is specific to libc++?