2023-05-23 11:15:06 +00:00
|
|
|
// Copyright (C) 2023 The Qt Company Ltd.
|
|
|
|
|
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only
|
|
|
|
|
|
|
|
|
|
import QtQuick
|
|
|
|
|
import QtTest
|
|
|
|
|
|
|
|
|
|
import qtprotobufnamespace.tests
|
|
|
|
|
|
|
|
|
|
TestCase {
|
2023-08-02 14:01:15 +00:00
|
|
|
name: "qtrotobufSyntaxTest"
|
2023-05-23 11:15:06 +00:00
|
|
|
|
|
|
|
|
property message_Uderscore_name underscore_name;
|
|
|
|
|
property messageUderscorename underscoreName;
|
|
|
|
|
property messageUnderscoreField msgUnderscoreName;
|
|
|
|
|
property followingMessageUnderscoreField fUnderscoreName;
|
|
|
|
|
property combinedMessageUnderscoreField combinedName;
|
|
|
|
|
property messageUpperCaseReserved upperCaseReserved;
|
|
|
|
|
property lowerCaseFieldMessageName lowerCaseFieldName;
|
|
|
|
|
property messageEnumReserved msgEnumReserved;
|
|
|
|
|
property messageUpperCase msgUpperCase;
|
|
|
|
|
property messageReserved msgReserved;
|
|
|
|
|
property priorMessageUnderscoreField underScoreMsg;
|
|
|
|
|
property lowerCaseMessageName lowerCaseMsg;
|
Long live mutable getters
The functionality is desirable by some users, we re-enable it.
New API addresses the core issue that is partially related to
QTBUG-119912, but has wider concequences in blind use in user
projects. We add the 'mut' prefix to all mutable getters to make
the mutable access explicit. Overload approach leads to unwanted
detaches not only whe is used be moc-generated code, but also
in user projects if developers do not pay enough attention to
const modifiers of their variables/references. We declined to
restore it, dispite it was the better looking API, in favor to
the code safety.
This also reveals the code clashing scenario, when the overload
might happen if the message has both 'a' and 'mutA' fields in
its definition. This scenario is kindly forbidden by our generator,
and sanitized at very early stages. We expect that it won't happen
in user projects, but even if it will, the solution is to rename
the field when generating Qt code. The serialization/deserialization
do not depend on field naming directly. json_name attribute also
will help to workaround this.
The undocumented ALLOW_MUTABLE_GETTER_CONFLICTS option allows clashing
the mutable getter names, but its usage currently limited by our
internal code only. The reason unfixed QTBUG-119912 issue in moc.
Once the issue is fixed, the moc version check should get the proper
version, but not '99' as for now and the ALLOW_MUTABLE_GETTER_CONFLICTS
will become public.
Another design solution is the use of overloaded functions that
return pointers, like it's done it the reference protobuf. But this
kind of API leaves the pointer ownership undefined and decided to
not be used.
[ChangeLog][Protobuf] The generated messages now have the mutable
getters for the fiels of the message type. The getters have 'mut'
prefix and implicily allocate the respective fields if needed, so the
use of intermediate message objects is not required.
Task-number: QTBUG-119913
Change-Id: I09b9ee37e1fbbe37b9c3cb501e92442da8ad3e4b
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
2025-03-14 11:40:54 +00:00
|
|
|
property nameClashingMutableGetters mutableGettersMsg;
|
2023-05-23 11:15:06 +00:00
|
|
|
|
2024-05-06 12:26:40 +00:00
|
|
|
function initTestCase() {
|
2023-05-23 11:15:06 +00:00
|
|
|
underscore_name.testField = -7
|
|
|
|
|
underscoreName.testField = 100
|
|
|
|
|
msgUnderscoreName.underScoreMessageField = 100
|
|
|
|
|
fUnderscoreName.underScoreMessageField = 1
|
|
|
|
|
combinedName.underScoreMessageField = 200
|
|
|
|
|
upperCaseReserved.import_proto = 123
|
|
|
|
|
upperCaseReserved.property_proto = 456
|
|
|
|
|
upperCaseReserved.id_proto = 789
|
|
|
|
|
lowerCaseFieldName.testField.testField = 7
|
|
|
|
|
msgReserved.id_proto = 34;
|
|
|
|
|
msgReserved.import_proto = 35;
|
|
|
|
|
msgReserved.property_proto = 36;
|
|
|
|
|
underScoreMsg.underScoreMessageField = 123
|
|
|
|
|
msgUpperCase.testField = 34
|
|
|
|
|
lowerCaseMsg.testField = 34
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
function test_Names_data() {
|
|
|
|
|
return [
|
|
|
|
|
{ tag: "msgReserved.id_proto == 34",
|
|
|
|
|
field: msgReserved.id_proto, answer: 34 },
|
|
|
|
|
{ tag: "msgReserved.import_proto == 35",
|
|
|
|
|
field: msgReserved.import_proto, answer: 35 },
|
|
|
|
|
{ tag: "msgReserved.property_proto == 36",
|
|
|
|
|
field: msgReserved.property_proto, answer: 36 },
|
|
|
|
|
{ tag: "underscore_name.testField == -7",
|
|
|
|
|
field: underscore_name.testField, answer: -7 },
|
|
|
|
|
{ tag: "underscoreName.testField == 100",
|
|
|
|
|
field: underscoreName.testField, answer: 100 },
|
|
|
|
|
{ tag: "msgUnderscoreName.underScoreMessageField == 100",
|
|
|
|
|
field: msgUnderscoreName.underScoreMessageField, answer: 100 },
|
|
|
|
|
{ tag: "fUnderscoreName.underScoreMessageField == 1",
|
|
|
|
|
field: fUnderscoreName.underScoreMessageField, answer: 1 },
|
|
|
|
|
{ tag: "combinedName._underScoreMessage_Field_ == 200",
|
|
|
|
|
field: combinedName.underScoreMessageField, answer: 200 },
|
|
|
|
|
{ tag: "upperCaseReserved.import_proto == 123",
|
|
|
|
|
field: upperCaseReserved.import_proto, answer: 123 },
|
|
|
|
|
{ tag: "upperCaseReserved.property_proto == 456",
|
|
|
|
|
field: upperCaseReserved.property_proto, answer: 456 },
|
|
|
|
|
{ tag: "upperCaseReserved.id_proto == 789",
|
|
|
|
|
field: upperCaseReserved.id_proto, answer: 789 },
|
|
|
|
|
{ tag: "lowerCaseFieldName.testField.testField == 7",
|
|
|
|
|
field: lowerCaseFieldName.testField.testField, answer: 7 },
|
|
|
|
|
{ tag: "underScoreMsg.underScoreMessageField == 123",
|
|
|
|
|
field: underScoreMsg.underScoreMessageField, answer: 123 },
|
|
|
|
|
{ tag: "msgUpperCase.testField == 34",
|
|
|
|
|
field: msgUpperCase.testField, answer: 34 },
|
|
|
|
|
{ tag: "lowerCaseMsg.testField == 34",
|
|
|
|
|
field: lowerCaseMsg.testField, answer: 34 },
|
|
|
|
|
]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
function test_Names(data) {
|
|
|
|
|
compare(data.field, data.answer)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
function test_enumValues_data() {
|
|
|
|
|
return [
|
|
|
|
|
{ tag: "MessageEnumReserved.Import == 0",
|
|
|
|
|
field: MessageEnumReserved.Import, answer: 0 },
|
|
|
|
|
{ tag: "MessageEnumReserved.Property == 1",
|
|
|
|
|
field: MessageEnumReserved.Property, answer: 1 },
|
|
|
|
|
{ tag: "MessageEnumReserved.Id == 2",
|
|
|
|
|
field: MessageEnumReserved.Id, answer: 2 },
|
|
|
|
|
|
|
|
|
|
{ tag: "MessageEnumReserved.enumValue0 == 0",
|
2023-07-06 17:54:10 +00:00
|
|
|
field: MessageEnumReserved.EnumValue0, answer: 0 },
|
2023-05-23 11:15:06 +00:00
|
|
|
{ tag: "MessageEnumReserved.enumValue1 == 1",
|
2023-07-06 17:54:10 +00:00
|
|
|
field: MessageEnumReserved.EnumValue1, answer: 1 },
|
2023-05-23 11:15:06 +00:00
|
|
|
{ tag: "MessageEnumReserved.enumValue2 == 2",
|
2023-07-06 17:54:10 +00:00
|
|
|
field: MessageEnumReserved.EnumValue2, answer: 2 },
|
2023-05-23 11:15:06 +00:00
|
|
|
|
2023-07-06 17:54:10 +00:00
|
|
|
{ tag: "MessageEnumReserved._enumUnderscoreValue0 is undefined",
|
|
|
|
|
field: MessageEnumReserved._enumUnderscoreValue0, answer: undefined },
|
|
|
|
|
{ tag: "MessageEnumReserved._EnumUnderscoreValue1 is undefined",
|
|
|
|
|
field: MessageEnumReserved._EnumUnderscoreValue1, answer: undefined }
|
2023-05-23 11:15:06 +00:00
|
|
|
]
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-06 17:54:10 +00:00
|
|
|
function test_enumValues(data) {
|
2023-05-23 11:15:06 +00:00
|
|
|
compare(data.field, data.answer)
|
|
|
|
|
}
|
Long live mutable getters
The functionality is desirable by some users, we re-enable it.
New API addresses the core issue that is partially related to
QTBUG-119912, but has wider concequences in blind use in user
projects. We add the 'mut' prefix to all mutable getters to make
the mutable access explicit. Overload approach leads to unwanted
detaches not only whe is used be moc-generated code, but also
in user projects if developers do not pay enough attention to
const modifiers of their variables/references. We declined to
restore it, dispite it was the better looking API, in favor to
the code safety.
This also reveals the code clashing scenario, when the overload
might happen if the message has both 'a' and 'mutA' fields in
its definition. This scenario is kindly forbidden by our generator,
and sanitized at very early stages. We expect that it won't happen
in user projects, but even if it will, the solution is to rename
the field when generating Qt code. The serialization/deserialization
do not depend on field naming directly. json_name attribute also
will help to workaround this.
The undocumented ALLOW_MUTABLE_GETTER_CONFLICTS option allows clashing
the mutable getter names, but its usage currently limited by our
internal code only. The reason unfixed QTBUG-119912 issue in moc.
Once the issue is fixed, the moc version check should get the proper
version, but not '99' as for now and the ALLOW_MUTABLE_GETTER_CONFLICTS
will become public.
Another design solution is the use of overloaded functions that
return pointers, like it's done it the reference protobuf. But this
kind of API leaves the pointer ownership undefined and decided to
not be used.
[ChangeLog][Protobuf] The generated messages now have the mutable
getters for the fiels of the message type. The getters have 'mut'
prefix and implicily allocate the respective fields if needed, so the
use of intermediate message objects is not required.
Task-number: QTBUG-119913
Change-Id: I09b9ee37e1fbbe37b9c3cb501e92442da8ad3e4b
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
2025-03-14 11:40:54 +00:00
|
|
|
|
|
|
|
|
function test_mutableGetters() {
|
|
|
|
|
mutableGettersMsg.field.data = 1;
|
|
|
|
|
mutableGettersMsg.mutField.data = 2;
|
|
|
|
|
|
|
|
|
|
compare(Number(mutableGettersMsg.field.data), 1);
|
|
|
|
|
expectFailContinue("", "Property getter of 'mutField' accesses non-const getter,"+
|
|
|
|
|
" which clashes to mutable getter of 'field'. See QTBUG-119912.")
|
|
|
|
|
compare(Number(mutableGettersMsg.mutField.data), 2);
|
|
|
|
|
}
|
2023-05-23 11:15:06 +00:00
|
|
|
}
|
