qt6-bb10/tests/auto/corelib/text/qanystringview
Marc Mutz 88b1c96239 QAnyStringView: fix char-ish ctors to not allocate memory
Extending the fromCharacter() tests to check for the construction to
be noexcept and implicit turned up a few bugs:

The constructor from char32_t was simply not marked as noexcept, even
though all its operations were. So just mark it noexcept.

The constructor from QChar, otoh, was never called, (certainly not for
rvalues), because QString happens to be constructible from QChar (and
QLatin1Char and QChar::SpecialCharactor), so due to perfect
forwarding, the if_convertible_to<QString> ctor won, allocating a
QString.

This is a regression of Qt 6.5 compared to Qt 6.4.

To fix this, exclude arguments that convert to QChar from matching the
if_convertible_to<QString/QByteArray> ctors, taking care to not match
those arguments that are already compatible_char<>s.

This, in turn, creates a problem for implicit QASV construction from
QLatin1Char and QChar::SpecialCharacter, because now that we've
excluded them from the if_convertible_to<QString> ctor, calling the
existing QChar or QString non-template constructors for these types
would require two user-defined conversions (from said type to
QChar/QString and from QChar/QString to QAnyStringView). That works
for explicit construction, but we need implicit convertability.

So bring out the big guns once more and add a perfectly-forwarding
ctor for anything convertible to QChar. QChar itself is actually
already handled by compatible_char<>, so the old QChar non-template
ctor can go. The extra copy of the QChar argument will be optimized
away by the compiler.

[ChangeLog][QtCore][QAnyStringView] Fixed a regression where
constructing a QAnyStringView from a char-like type (QChar,
QLatin1Char, ...) would first construct a QString and only then
convert that to QAnyStringView.

Amends 812a0d3125.

This change is forward and backward BC and SC, but not
behavior-compatible: certain operations detectably change
noexcept'ness, and some arguments may now cause the resulting
QAnyStringView to have a different encoding (though I really tried
hard to avoid that).

Since it's a regression, I proposed to pick this to the affected
branches, 6.7 and 6.5 (6.6 is already closed at this point).

Pick-to: 6.7 6.5
Fixes: QTBUG-125735
Change-Id: I86f37df5d80bee36db27e529c017cb73995a6831
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2024-05-29 14:24:30 +02:00
..
.gitignore
CMakeLists.txt QAnyStringView: use new comparison helper macros 2024-03-02 00:12:55 +01:00
tst_qanystringview.cpp QAnyStringView: fix char-ish ctors to not allocate memory 2024-05-29 14:24:30 +02:00