[Development] Requesting forward BC exception for QtWaylandCompositor in 6.2 and 5.15

[Marc Mutz]

s/that the/that this is the only workable solution/
________________________________
From: Marc Mutz <marc.mutz at qt.io>
Sent: Wednesday, February 16, 2022 11:20 AM
To: Lars Knoll <lars.knoll at qt.io>
Cc: Qt development mailing list <development at qt-project.org>
Subject: Re: [Development] Requesting forward BC exception for QtWaylandCompositor in 6.2 and 5.15

Nope, doesn't work. I keep hitting a Clang 10 bug: https://godbolt.org/z/z9K8fc5ce (works in Clang 11).

I think this is what I hit in the past, too, and Clang 10 will not let up until that weird-const overload is gone. So the only way to fix it for Clang 10 is to take the fwd-BC break and just back-port the 6.3 solution. I've convinced myself that the

v10.0.0 is the Clang shipping with Ubuntu 20.04.

If you skip to Clang 11, 12, 13, you will see that, while not producing a hard error anymore, it still produces the bogus reversed-operator warning.

Thanks,
Marc

________________________________
From: Marc Mutz <marc.mutz at qt.io>
Sent: Wednesday, February 16, 2022 9:37 AM
To: Lars Knoll <lars.knoll at qt.io>
Cc: Qt development mailing list <development at qt-project.org>
Subject: Re: [Development] Requesting forward BC exception for QtWaylandCompositor in 6.2 and 5.15

Hi Lars,

> * Is there a work-around for the developers with the current state, e.g. by adding some casts?

There are two situations here:


  *   those that control the creation of the QWaylandBufferRef objects can just choose to not make the LHS const, swapping RHS and LHS if need be (as all existing code must currently do, because it wouldn't compile otherwise)
  *   those that don't control the creation of these objects (STL algorithms come to mind) would have to const_cast const away, and it's likely those which do won't understand that this may introduce UB

> * Could you add the missing operators inline, so they don’t add new symbols?

No. As explained in the initial email, as well as the BR and the Gerrit change, the problem is that we'd need at least the op==(const, const) overload out of line, because we can map all other operator overloads to that (by adding const). But we cannot remove const to call the existing member operator, that would be UB if the object was originally declared const.

In addition, we'd first have to un-export the class, so that new inline members wouldn't be automatically exported (Windows only, don't know whether QtWaylandCompositor targets Windows at all).

Did I mention we shouldn't export non-polymorphic classes wholesale, ever? I'm not sure. Consider it mentioned now 🙂

Adding the missing operator overloads as free functions (even if hidden friends) didn't work, probably because name lookup stops when it finds the member operators.

If Windows is not a target for QtWaylandBufferRef, then I think I could add all missing operators as members with only op==(const, const) being out-of-line. That would be forward-BC for all code that wouldn't have caused a compile error in either C++17 or C++20 already.

Actually, come to think of it, that's also a solution for Windows: un-export the class, then add these members.

Thanks for rubber-ducking 🙂
Marc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220216/48ec9bbf/attachment.htm>