[Development] INTEGRITY

[Mutz, Marc]

On 2019-09-18 17:33, Thiago Macieira wrote:
> On Wednesday, 18 September 2019 08:16:46 PDT Giuseppe D'Angelo via 
> Development
> wrote:
>> > We've never required C++11 Standard Library. We've only required the core
>> > language and the integrity compiler does support it just fine.
>> 
>> Not really, it also fails on constexpr:
>> 
>> https://codereview.qt-project.org/c/qt/qtbase/+/264550
> 
> No, it has a bug in its existing constexpr implementation. That's 
> different.
> MSVC 2015 officially supported constexpr, but we turned it off for them
> because it was too buggy.
> 
> Are we sure to be running the latest version of the GHS compiler?
> 
>> According to INTEGRITY documentation: "Namespace member
>> std::condition_variable is not supported, along with any library 
>> functions
>> related to it (for example, std::notify_all_at_thread_exit)."
>> 
>> So there's no way out of this.
> 
> Seems like it. Like I said, we've never required the C++11 standard 
> library
> and we need to be sure the feature we need is supported before we 
> commit to
> it.

https://www.qt.io/blog/2016/06/16/qt-5-7-released
> "we require a C++11[-]compliant compiler to build [...] Qt"

The std library is not optional, unless you mean that Qt explicitly 
targets free-standing implementations. That, however, is not mentioned. 
When we dropped support for pre-C++98-compilers in 5.0, we also removed 
-no-stl, because that's natural. There's a technical distinction between 
the compiler and the std library, but from the POV of the standard, in 
hosted environments, there isn't.

QNX was a case where an older library (by a different vendor) shipped 
with a newer GCC, and that limited the use of library features in Qt, 
but that particular platform is now gone, and if Integrity has the same 
problem as that QNX toolchain had, it should have been removed along 
with it. Otherwise, we could've kept QNX along for the ride with no 
extra cost to the Qt project.

I think we should be way past caring for non-conforming platforms. We 
decided to use SD-6 macros for post-C++14 feature detection, even 
thought that meant that none of the features were detected for MSVC, a 
much more important platform that Integrity.

The worst thing is that INTEGRITY claims support for C++14 on it's 
homepage, even citing the official name of the standard. It *does* 
provide std::condition_variable, proven by the fact that the header 
exists, can be included and use of std::condition_variable is compiled 
without error, so it's clearly positioning itself as a hosted 
environment, not a free-standing one. That means that 
std::condition_variable needs to be available, or else you're 
non-conforming. If you're advertising with conformance, but are in fact 
nonconforming, that's misleading advertising, which, at least in EU law, 
is punishable.

That, and the fact that the pthreads version we're replacing in 
QWaitCondition was working before, makes me think that there can be no 
reason not to provide std::condition_variable, because it totally models 
pthread's condition variables, so either we're using an old version of 
the tool-chain, or the OS, or we're indeed just missing a linker flag.

But no-one seems to know anything (and there's _still_ no maintainer for 
the platform listed in the wiki). The best reaction I get is to revert 
the patch that introduced use of std::condition_variable. If you would 
have a look at how much complexity is taken out of the Qt implementation 
of QWaitCondition by simply implementing it on top of the std one, incl. 
deleting a rather recent change for just Android, it should be obvious 
how this hurts maintainability of Qt. I know Thiago revels in such 
details, but there're also those Qt devs who cannot bear the presence of 
a find_if. What would the latter half have to say about the four or so 
different mutex implementations? While the mutex implementations can be 
argued to actually be worth it (though they could be reduced to two: 
futex and std::mutex), because futex outperforms std::mutex, 
QWaitCondition is _much_ slower (on Windows an order of magnitude) than 
std::condition_variable.

Standing in the way of Qt maintainability in this way should disqualify 
INTEGRITY as a supported platform until it's resolved.

So, I update my requests:

1. List a maintainer for INTEGRITY in https://wiki.qt.io/Maintainers
2. That maintainer should either find the missing linker flag, or file a 
bug with Integrity
3. If there's a work-around (providing those missing functions in Qt, 
e.g.), apply it, else
4. drop Integrity support (or update to a newer version) ASAP (for Qt 
5.15 if not 5.14).

Thanks,
Marc