[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

Tue Oct 12 06:44:30 PDT 2021

aaron.ballman added a comment.

In D108643#3057417 <https://reviews.llvm.org/D108643#3057417>, @rjmccall wrote:

> I think the immediate way forward is that we can continue to document this as an experimental feature with an unstable ABI, just with a new name.  We do not need to tie these things together as long as we agree that the feature is experimental and the ABI might change.  Perhaps it should be enabled by an experimental flag until the ABI is official?

We've already documented that the ABI is being actively developed in the release notes, in the ABI document, and in LanguagateExtensions.rst, so the ABI information is widely available. I'm fine documenting the *ABI* as being unstable, but I want to make sure we don't give the impression that the *feature* is experimental (it's in a standard that is starting to be finalized for publication), so I'd be opposed to putting a standard feature behind a feature flag (beyond -std).

This is spiraling into a pretty large set of ongoing changes when the original intent was "rename the thing we were already happy with to its new, standard name with the same semantics". Would it make sense to separate some concerns here, as this is starting to block further work? At a high-level, I'm thinking: this patch does the rename, adds the release notes/documentation to be clear that the ABI is not yet stable for the feature, and a second patch is added for the ABI documentation and eventual codegen changes needed for it? This would unblock us from doing additional follow-up work (like adding the `BITINT_MAXWIDTH` macro to limits.h, which would not make sense without having a type named `_BitInt`) while giving us the Clang 14 release time frame to clean up the ABI requirements. WDYT?

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108643/new/

https://reviews.llvm.org/D108643