WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out:
- Deprecates _ExtInt with a fix-it to help users migrate to _BitInt.
- Updates the mangling for the type. MSVC switches from _ExtInt to _BitInt in the private mangling name, and Itanium uses newly-proposed-but-not-yet-accepted basic datatype names (https://github.com/itanium-cxx-abi/cxx-abi/pull/129).
- Updates the documentation and adds a release note to warn users what is going on.
- Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern.
- Adds new tests for the new diagnostic behaviors.
I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
There is one piece of work that's still outstanding: the test files use "ext int" in their name. Renaming the tests would make it harder to see that the changes in the test files are about the renaming of the type because it would show up in Phab as a delete + create of a new file. I will rename the files to use "bit int" in their name as a follow-up once this lands.
Note: I would like to hold off on landing this until the Itanium ABI proposal has been accepted, but I think it's reasonable to start getting Clang review feedback now as I don't expect the ABI discussion to take a significant amount of time.
I think you should recommend that ABIs codify that by reference to your specification. Perhaps:
Now, I am assuming that this specification will be complex enough that ABI maintainers won't want to just copy into their specifications. Maybe I'm wrong about that, but I think it will be fairly long by the time it's finished — not, like, Itanium C++ ABI long, but it might be 3-4 pages. If we want to support including this by reference, we need to think about what that reference looks like. I think there are two key parts of that: first, it should explicitly name a version of this document, and second, it should give the parameters that we've listed out below. Basically, someone should be able to see that and have no doubt about what the ABI is.
I would suggest this recommended reference:
To make versioning work, the version history should (1) explicitly say what version this is and (2) be limited to major semantic versions, where you actually change the intended ABI rather than just making editorial changes. (If you never need to do that, great, but you should set up to make it possible.)