I relied on the compiler pointing me to all places where the implicit cast to QString no longer works/is existing if the macro QT_NO_CAST_FROM_ASCII is set. But now we found out that there are traps with this approach: at least QScriptValue has some overloads of its constructors which among string variants also includes the
QScriptValue(bool value); QScriptValue(const QString &value); QScriptValue(const QLatin1String &value); #ifndef QT_NO_CAST_FROM_ASCII QT_ASCII_CAST_WARN_CONSTRUCTOR QScriptValue(const char *value); #endif
Now guess what the compiler prefers for code like
QScriptValue value; // second argument to setProperty(...) is a QScriptValue // all QScriptValue constructors are implicit value.setProperty(name, "some string");
QScriptValue(const char *value); no longer is available… indeed, the constructor with the
bool parameter. Picks it silently and continues its work without pointing me to the issue.
This could have been prevented if I had used the macro
QT_ASCII_CAST_WARNINGS before, which seems to be usable to find all places where the implicit conversion is used, by issuing warnings during compilation. But it seems undocumented, at least it is not mentioned in the
QString API dox and $SEARCH_ENGINE did not show up with something as well (complain about that is up as QTBUG-20821).
The problem with the broken structure descriptions in JS has been fixed by Alex for the upcoming Okteta 0.7.1 (will be part of KDE Apps 4.7.1) by using the proper QLatin1String wrapper for any (implicit) calls to the QScriptValue constructor, so look out for that version.