replaces vector<signed char> with vector<bool>

re-adds header to modulemap, fixes test to work in C++03 mode (apparently lambdas aren't backported)

adds test to improve confidence

In D125283#3535047, @ldionne wrote:

In D125283#3532818, @cjdb wrote:

I'm not sure why there's so much resistance to reverting. libc++:

1. has users with broken code right now;
2. actively supports uniform_int_distribution<__int128_t>, which is also undefined (I don't get why you consider signed char, unsigned char, char, and bool to be problematic, but not __int128_t and unsigned __int128_t);
3. has licence to make it an extension without Microsoft/STL's support;

You can also propose standardising this right now.

I don't know whether our distributions actually work with these types. This explicit rejection was added in D114920, which was itself prompted by discussions on D114129, whose goal was to fix http://llvm.org/PR51520 (an overflow in uniform_int_distribution<__int128_t>). What tells us that we don't have similar problems with uniform_int_distribution<char> & friends. They are not tested, so anything is possible. Then, add the fact that the Standard made those undefined, which I consider a red flag; without diving into the implementation of those distributions, I'm thinking there might be a good reason why they didn't require implementations to support those types, e.g. maybe the usual algorithms don't work properly for types of that size.

So, given this uncertainty, I think it's better for everyone (our users especially) to get this compile-time error. However, if this patch showed that our implementation indeed supports these types properly, it would become a simple question of "do we want to support them as an extension, like we do for __int128_t", and that's easier to answer.

If you can add tests to show that distributions work with these types, I'd be OK with that. We still have until June 8th to cherry-pick to LLVM 14, so we could even backport to LLVM 14 and avoid breaking users for just one release (which would be very annoying indeed).

In D125283#3531777, @ldionne wrote:

In D125283#3528195, @EricWF wrote:

GCC ships this as an extension. I can't find a reason why the extension would be non-conforming or dangerous, and it seems like a safer way for users to generate char values, rather than expecting the user to correctly pass the numerical_limits<char>::max() to the constructor.
I think we should reach out to someone at Microsoft (maybe STL), and see how open they are to shipping this as an extension. If they're willing then we avoid the portability trap that we're trying to protect users from.

@CaseyCarter Would you be willing to, as an extension, support char in the random distributions? This is currently marked as being undefined by http://eel.is/c++draft/rand.req.genl#1. If you are willing, then I could also write a short paper to suggest adding it to the spec, since all three major implementations would support it.

rebases for D116203's sake

• fixes wchar_t (wasn't supported) and charX_t (all three went to an 8-bit type)
• makes underlying type for signed wchar_t int rather than wchar_t
• adds tests for these types

makes __is_destructible and __is_nothrow_destructible KEYCXX instead of KEYMS (attention @aaron.ballman)

rebases

responds to the vast majority of open feedback

In D125283#3507460, @ldionne wrote:

@cjdb @CrystalSplitter I understand your frustration with something that "used to work" and doesn't anymore. My main concern is that there must be a reason why these types are disallowed in the first place -- did you try to investigate why there was such a restriction in the Standard in the first place? If you do, perhaps we can use the result of that investigation to better inform on whether we should support that extension (or just lift it and change the Standard).

In D125283#3506131, @ldionne wrote:

http://eel.is/c++draft/rand.req.genl#1 says that the effect of instantiating one of these templates with a type that isn't in <list-of-allowed-types> is undefined. That means it's undefined behavior, and we strive to catch cases where users rely on undefined behavior for various reasons, notably to make their code more portable (https://godbolt.org/z/E6oGjfjhP), but also because we can't guarantee what the behavior is for such inputs.

I support turning it on by default. I'm simply passing on the message.

I'm in favour of this, but @rsmith warned me a little while ago that we mightn't be able to have stuff like this on by default because scripts probably depend on specific compiler output. Hyrum's Law strikes again :(

Thanks for working on this!

Thanks!

fixes formatting

• handles VLAs
• adds __is_referenceable which is used by portions of the standard library

removes discrete number of elements in small vector

• finishes __is_move_constructible and __is_move_assignable
• fixes detecting C++ mode
• clang-formats

• catches some missing things that only handled __underlying_type
• makes __remove_pointer remove address spaces (otherwise it'd create types like int __attribute__((address_space(1))))

achieves harmony with libstdc++

responds to all feedback from the last round, except for handling __remove_cv in libstdc++ land

adds __is_copy_constructible, __is_copy_assignable, __is_move_constructible (WIP), and __is_move_assignable (incomplete)

• updates mangling tests to check everything added
• adds __remove_restrict (per offline conversation with @aaron.ballman we're deferring __remove_all_qualifiers to a later CL)
• removes programmability for BuiltinEnumUnderlyingType, BuiltinAddPointer, and BuiltinDecay with respect to UTTKind since they don't need this

In D116203#3435729, @aaron.ballman wrote:

In D116203#3434761, @rjmccall wrote:

In D116203#3434515, @cjdb wrote:

In D116203#3431612, @rjmccall wrote:

In D116203#3430332, @aaron.ballman wrote:

In D116203#3425512, @cjdb wrote:

I've noticed that libstdc++ has using __remove_cv = typename remove_cv<T>::type, which causes Clang to chuck a wobbly. Changing from KEYWORD to TYPE_TRAIT_1 didn't seem to fix anything.
Is there a way we can work around this, or should we just rename __remove_cv and friends to something else?

You could work around it by taking note that you're in a libstdc++ system header and do a special dance, but because these are in the implementation's namespace, I think it's probably kinder for everyone to just pick a different name.

I was hoping we could do something similar to struct __remove_cv which would issue a warning?

If you wanted to be especially mean, you could go with __remove_cvr, but I'd suggest __remove_cv_qualifiers instead. However, what about restrict qualifiers? We support them in C++: https://godbolt.org/z/11EPefhjf

Along with a fair number of other vendor qualifiers, yeah. I think you have to make a policy decision about whether the intent of std::remove_cv is really to just remove CV qualifiers or to produce an unqualified type (at the outermost level). The former is probably more defensible, even if it makes the transform less useful in the presence of extended qualifiers.

I'm partial to std::remove_cv being faithful to its name, unless existing implementations do something else already. I don't mind adding support for the other stuff, but if there's more than just add/remove restrict, we're going to have a combinatorial explosion for removes. Is there an alternate way we can approach this?
Possibly:

template<class T>
using remove_const_t = __remove_qualifiers(T, const);


template<class T>
using remove_reference_t = __remove_qualifiers(T, &, &&);

template<class T>
using remove_rcvref_t = __remove_qualifiers(T, const, volatile, restrict, &, &&); // rcv instead of cvr to prevent a typo with remove_cvref_t

I don't think it's worth adding that parsing complexity for a builtin that we expect to only be used in system headers. Let's just remove const and volatile and leave other qualifiers in place.

I come down on the opposite side of the fence and think it should remove all qualifiers (or that should be an interface we support in addition to removing just cv qualifiers). WG14 adopted https://www9.open-std.org/jtc1/sc22/wg14/www/docs/n2927.htm into C23 with a remove_quals function which removes *all* qualifiers (including _Atomic), as an example. But even in C++ mode, I fail to see why we wouldn't want <some> interface for stripping __restrict the same as const or volatile along with some interface for stripping all qualifiers period (I don't see a huge need for a __remove_cvr if we have the ability to remove all qualifiers, so I don't think we need the combinatorial explosion or a complex interface). Basically -- if we have extensions like __restrict or _Atomic, we should fully support them rather than halfway do it.

• updates name of __remove_cv to __remove_cv_qualifiers
• updates mangling
• updates mangling test

In D116203#3431612, @rjmccall wrote:

In D116203#3430332, @aaron.ballman wrote:

In D116203#3425512, @cjdb wrote:

I've noticed that libstdc++ has using __remove_cv = typename remove_cv<T>::type, which causes Clang to chuck a wobbly. Changing from KEYWORD to TYPE_TRAIT_1 didn't seem to fix anything.
Is there a way we can work around this, or should we just rename __remove_cv and friends to something else?

You could work around it by taking note that you're in a libstdc++ system header and do a special dance, but because these are in the implementation's namespace, I think it's probably kinder for everyone to just pick a different name.

I've noticed that libstdc++ has using __remove_cv = typename remove_cv<T>::type, which causes Clang to chuck a wobbly. Changing from KEYWORD to TYPE_TRAIT_1 didn't seem to fix anything.
Is there a way we can work around this, or should we just rename __remove_cv and friends to something else?

• fixes assert failure
• removes __add_{const,volatile,cv}

In D116203#3255018, @aaron.ballman wrote:

In D116203#3220165, @aaron.ballman wrote:

The summary for the patch explains what's being added, but there's really no information as to why it's being added. Why do we need these builtins?

Btw, I still think the patch summary should be updated with this information.

provides most of the updates to commentary from ages ago

Thanks for working on this!

adds no-locale and no-thread to list of unsupported

Puts threading_support.h into config files

changes <threading_support.h> to "threading_support.h"

adds clang-13, apple-clang-{11,12,13} as unsupported

rebases to ToT, which I'd forgotten to do before last push

Reviving this patch since we need this support

rebases to activate CI

• makes it harder to accidentally build llvm-libgcc by removing it from LLVM_ENABLE_RUNTIMES=all
• installs shared objects properly

cleans up a few things

responds to feedback

qualifies something that Clang missed, but MSVC caught

• qualifies things that weren't caught by the modules build
• adds using-declarations for some of the more commonly used types so that they don't need to be qualified

creates namespace alias

quick CMake fix

gets CMake scripts into a decent state

Thanks for working on this! I'm overall very happy, but I don't see a test case for a unary move originating from another namespace.

broadens armhf detection

changes to SIZEOF_POINTER >= 8

changes how GLOBAL_32BIT and GLOBAL_64BIT are enabled

changes how the version script is laid out so that global symbols are all listed first, and exclusive symbols are listed afterward

applies @danielkiss' feedback

In D108416#3277189, @MaskRay wrote:

Could you please comparing the symbol set with GCC libgcc_s.so.1 for these architectures you mostly care about?

• re-adds generate_version_script.py
• responds to @MaskRay's feedback

• collapses the version script preprocessing into a single version script that's now run through the C preprocessor
• adds pseudo-detection for arm-*-*-gnueabihf

updates documentation to reflect status quo

restores the version scripts, but instead makes them generated when invoking the build

updating to C symver file

What's the status of this patch?