C++/library requirements for Plasma 5.26

[Bernie Innocenti]

On 07/07/2022 05.55, Ivan Čukić wrote:
> Hi Nicolas,
> 
> While I've been known to request newer and newer compilers
> for everything, and while I do support this request for GCC 10
> and Clang 11, I'm not sure I'd support requiring QCoro and
> coroutines.
> 
> Not because of QCoro itself, but that clang doesn't yet officially
> support coroutines. According to [1] they have a partial support
> since version 8, and according to [2] they might lead to problems
> when coroutines might be resumed on a wrong thread (if I'm
> reading this correctly), with a comment 'This feature requires
> further analysis of the C++ Standard to determine what work is
> necessary for conformance.'

You might very well not be reading this correctly, as it's phrased very 
ambiguously:

   The optimizer does not yet handle TLS with __attribute__((const))
   attribute correctly. There can be issues where the coroutine may
   resume on a different thread.
   This feature requires further analysis of the C++ Standard to
   determine what work is necessary for conformance.

These three sentences are not describing three unrelated issues. They 
should be interpreted as subordinates:

1. Coroutines may interact weirdly with thread-local storage (TLS).

2. The optimizer is normally allowed to cache the result of calls which 
are marked __attribute__((const)).

3. If a coroutine resumes from co_await on a different thread, the 
cached result of a const function which accesses a TLS variable will be 
based on the previous thread

4. "This feature" in the last sentence refers to this rather exotic 
interaction of coroutines, thread-local storage and const functions 
(which are a GNU extension, not part of the C++ standard).

This bug has a real-world case where this could happen due to 
pthread_self() being a const function which accesses TLS to retrieve the 
current thread's ID: https://bugs.llvm.org/show_bug.cgi?id=47833


> Clang development seems to have slowed down a bit so I'm
> not sure how viable is pushing C++20 to Plasma just yet.

Modules, Concepts and Coroutines are huge new features that will take 
years to mature.

However, C++20 also brought dozens of smaller language and library 
improvements that have been working just fine in both Clang and GCC even 
before the C++20 draft was finalized:

   https://android-review.googlesource.com/c/platform/system/netd/+/1161045

I don't remember encountering any Clang bugs in 2 years of usage in 
AOSP, and it's now enabled in more places:

 
https://cs.android.com/search?q=cpp_std.*(experimental%7Cc%5C%2B%5C%2B2%5B03a%5D%7Cgnu%5C%2B%5C%2B2%5B03a%5D)%20file:Android.bp


> Especially since most of us compile with GCC - if we are able
> to overlook bugs that our patches introduce for dark-theme
> users because we use and test on the light one, I can't dare
> to imagine issues we can introduce to Clang-based distros. :)

Would be good to have CI pipelines building all of KDE with the oldest 
officially supported versions of GCC and Clang.

Ok, building and possibly also *testing* ;-)

> Cheers,
> Ivan
> 
> p.s. From a personal standpoint, yes, I'd really like to be able to
> use QCoro in Vault...
> 
> [1] https://en.cppreference.com/w/cpp/compiler_support/20
> [2] https://clang.llvm.org/cxx_status.html
> 

-- 
_ // Bernie Innocenti
\X/  https://codewiz.org/