On Sun, 1 Mar 2026 06:01:26 GMT, Kim Barrett <[email protected]> wrote:
>>> And this bug may cause us further problems. Anyone who tries to use
>>> `std::stable_sort` is going to introduce a clang+glibc12 problem. And
>>> turning
>>> off deprecation warnings more widely isn't especially appealing.
>>
>> If the `std::stable_sort` beening invoked inside jdk, maybe we can disable
>> the depracated warning by "#pragma clang diagnostic ignored", but this make
>> code looks ugly.
>>
>> ```c++
>> #ifdef __clang__
>> #pragma clang diagnostic push
>> #pragma clang diagnostic ignored "-Wdeprecated-declarations"
>> #endif
>> #include <algorithm>
>> #ifdef __clang__
>> #pragma clang diagnostic pop
>> #endif
>>
>> int main() {
>> std::stable_sort((int *)0, (int *)0);
>> }
>
>> > And this bug may cause us further problems. Anyone who tries to use
>> > `std::stable_sort` is going to introduce a clang+glibc12 problem. And
>> > turning
>> > off deprecation warnings more widely isn't especially appealing.
>>
>> If the `std::stable_sort` beening invoked inside jdk, maybe we can disable
>> the depracated warning by "#pragma clang diagnostic ignored", but this make
>> code looks ugly.
>
> The specific case of `std::stable_sort` isn't going to be a problem for
> HotSpot (at least), because `get_temporary_buffer` is using the default global
> allocator, which we don't allow. But yes, for other parts of the JDK one could
> disable the warning that way, perhaps also somehow conditionalizing it for
> using glibc12. But yuck! Hopefully we'll just never run into this problem
> elsewhere.
Thanks for the suggestions and reviews @kimbarrett @erikj79
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29919#issuecomment-3989166605
