Change the way we handle them. Add the special registry so any
type can register its special JSON (de)serializer independently.
Move the timestamp serializer from the generic JSON serializer
implementation to QtProtobufWellknownTypes library so we remove
the weak backward link from QtProtobuf module to its dependency.
The introduced mechanism is also scalable, and allows adding other
types that have similar special JSON serialization.
Task-number: QTBUG-130555
Task-number: QTBUG-120214
Change-Id: I56ce2e43a00262069281871d5f903f1e94abef83
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
When using the nested Qt types from either QtCore or QtGui packages
protobuf generator doesn't consider these types when generating the
includes.
Fixes: QTBUG-132182
Pick-to: 6.8 6.9
Change-Id: I6f0de0119ff9f8fd8109dd621a0d20f5dca31003
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
Generating the aliases for protobuf QList types leads to the name
clashing when users want ot introduce messages that have name
consisting of previously defined message name and Repeated suffix,
e.g.:
message MyMessage {
}
message MyMessageRepeated {
}
We shouldn't prohibit the above scheme in our generators and generate
the respective messages correctly. The only possible solution -
complete removal of the protobuf messages QList aliases.
Generator still generates the aliases guarded by the
QT_USE_PROTOBUF_LIST_ALIASES macro. The macro is enabled by
Qt::Protobuf when building using CMake, but can be disabled at any
time by setting QT_USE_PROTOBUF_LIST_ALIASES property on protobuf
target to avoid name clashing.
[ChangeLog][Protobuf] qtprotobufgen doesn't generate protobuf message
QList aliases. All usages of aliases should be replace by respective
QList types. Aliases are still generated and are guarded by the
QT_USE_PROTOBUF_LIST_ALIASES macro in the generated code. The macro
is enabled by default and can be disabled using
QT_USE_PROTOBUF_LIST_ALIASES target property.
Fixes: QTBUG-129652
Pick-to: 6.8 6.9
Change-Id: I026755b36985eef01a6851156d9c9cfff141d247
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
The generation was broken for proto filenames, which where
invalid identifier, since the filename is used at several places in the
generation process.
This became evident for the protobuftyperegistrations and traditional
filename header guards.
Solve this by transforming the basename into a valid identifier.
Also add a testcase on the highest point of abstraction for the
generators (qtgrpcgen).
Fixes: QTBUG-131417
Pick-to: 6.8
Change-Id: I492907881913f8b43ebf365a9e1fe38062113c3c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Avoid removing and appending header files suffixes where this is not
intentional. Change the default internal header file template and
always add the suffix explicitly, where required.
Pick-to: 6.8
Change-Id: I1fff1d3813700d6387964d5411970b21ecb4a2e6
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
The ifdef based header guard has potential downside for the protobuf
code generating. '.proto' files may have the same name but locate in
different directories. We could encode the package name in a header
guard too, but .proto files may share the same package as well.
The use of 'pragma once' instead of ifdef based header guard solves
this issue. Add the 'HEADER_GUARD' generator and qt6_add_protobuf
options, so users may switch back to the ifdef based guard if they
want. The option accepts one of the two values:
- pragma
- filename
Change-Id: Ice0a3b2baa76752a1ee4b3507b7f3163738455ee
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
Sort includes according to the common Qt rules:
- internal header first, Qt header files next, system header file last
- split includes to sections
- use ascending order for each include section
Cleanup redundant and unused header files from the generated code.
Pick-to: 6.8
Task-number: QTBUG-123625
Task-number: QTBUG-123626
Change-Id: Ibecdecd4fb61e3b554746d623ed691be5ee6f57d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Use the proper file names when generating the guards for the header
files instead of using the hardcoded suffixes.
Refactor the filename calculations in the generator as the
drive-by change.
Pick-to: 6.8
Task-number: QTBUG-123625
Change-Id: Ie1e6c7ecb5dc611b72bd01228524701157b26d4b
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
"Some types are registered automatically and do not need this macro:
...
- Classes that have a Q_GADGET macro
" (c)
Pick-to: 6.8
Task-number: QTBUG-123626
Change-Id: I5c73d61a51341328d37e71290633f484a3cbdfb8
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The include is unused in the generated protobuf code, but is used in
the generated gRPC code. Make it gRPC specific.
Pick-to: 6.8
Change-Id: I25ad6ffe88e46a63d928b09362211d6d590eb625
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Make the generating of C++ exports common for both generators.
The confilicting generation should be resolved by the tools that
running the generators. Qt CMake API handles this situation.
Fixes: QTBUG-121856
Pick-to: 6.7
Change-Id: Ie2452f52d755ade2909107885dac774ff8678daa
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Consider the EXPORT_MACRO CMake argument of qt_add_<protobuf|grpc>
calls.
Add the support for the EXPORT_MACRO option extras to the
qt<protobuf|grpc>gen generators. The extras now allow setting:
- export file name
- boolean flag that indicates if export file needs to be generated
The EXPORT_MACRO option of the generators now has the following format:
EXPORT_MACRO=<export_name>[:export_filename[:<true|false>]]
If export_filename is not set, then generators fall back to the previos
behavior and use the export_name as the export filename base, the file
will be generated unconditionally. If export_filename is set and the
follow boolean flag is not set or is set to false, generators skip the
generating of the export file.
[ChangeLog][Protobuf][qtprotobufgen] EXPORT_MACRO option now has the
following format:
EXPORT_MACRO=<export_name>[:export_filename[:<true|false>]]
New option extras allow setting the generated export filename and
control if it should be generated at the generator run.
[ChangeLog][GRPC][qtgrpcgen] EXPORT_MACRO option now has the
following format:
EXPORT_MACRO=<export_name>[:export_filename[:<true|false>]]
New option extras allow setting the generated export filename and
control if it should be generated at the generator run.
Pick-to: 6.7
Fixes: QTBUG-121854
Change-Id: Ifff6506ab363d18dc417f222e9929d7eba135d8a
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Move functionality related to the registration of the protobuf messages
to a separate header/source files.
Task-number: QTBUG-120931
Change-Id: I6076b41139d43982148e46f5f315808509c4db65
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
The include is not used in the generated code.
Pick-to: 6.6 6.7
Change-Id: I94c9649d7f9130b796b44de578b32ae4acd3655e
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
When serializing/deserializing floating point numbers to/from JSON we
should consider the sign bit. This allows serializing -0.0 in JSON.
TODO: Signed zeros are not supported by cbor. See QTBUG-120077
Pick-to: 6.7
Task-number: QTBUG-119392
Change-Id: I587ab23269845f3de34a27a7335635ac0d4baebb
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
'optional' fields is the legacy mechanism from 'proto2' times. In
'proto3' schemes this keyword changes the 'presence' handling of
the fields that are marked as 'optional'. By default protobuf
messages(serializer to be precise) treat all fields as optional.
This means that if field has the default value(0, 0.0f, false, nullptr)
the field will not be serialized at all. This mechanism can be
overwritten using the 'optional' attribute or keyword. If the message
field is marked as 'optional' it gets the following methods in addition
to the regular field one:
- clear<fieldName>
- has<fieldName>
These methods allow to clear the value and to check whether the field
was ever set. The optional fields get serialized if they were
explicitly set in the message, even if they have the default value.
This is the key difference that this attribute/keyword makes on
the serialization process.
[ChangeLog][QtProtobuf] All message fieds now have 'has' methods
that indicate if message was initialized and contain value or not.
Task-number: QTBUG-103978
Change-Id: Ia948be85486175bb2d81357352f5c04da12af846
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Protobuf allows the following construction:
message A {
enum AEnum {
AVal0 = 0;
}
B.BEnum val = 1;
}
message B {
enum BEnum {
BVal0 = 0;
}
A.AEnum val = 1;
}
This requires forward declaration of nested enums, that is not possible
in C++. To solve this problem we may do the same trick that we do
for nested messages already.
This patch moves the nested enum type out of class to the
_QtProtobufNested namespace. The solution require the enum name
specification when using enums from this moment, since the owning
messages only contain type aliases now. So from example above to access
the AVal0 you need to use the full qualifier:
A::AEnum::AVal0
The new generated code structure registrates Qml types using the built-in
macros, that unlocks direct linking of backing library without the need
of Qml plugin usage.
[ChangeLog][Protobuf] Nested enums moved out of message classes to the
nested namespace, same as the nested messages.
[ChangeLog][Protobuf][Qml] The geneated protobuf Qml modules do not
require the use of Qml plugins.
Fixes: QTBUG-115800
Change-Id: Ia67fcbecf492c3fd41350eada4d62fc9e5ea4dab
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The missing message or enum declarations shouldn't lead to an error
when running protobuf generator. This only means that the .proto file
needs no processing.
Pick-to: 6.5 6.6
Change-Id: I80c81ebd04024c1e08883b8a0b9cf572b0c3aa1d
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Use the old syntax-based check if libprotoc version is less than
3.12.
Amends dd04edf72f
Pick-to: 6.6
Task-number: QTBUG-115693
Change-Id: Ia411f70337a14843ff320b7c75ab140f5021f2f6
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Enable 'optional' fields support in Qt generators. This only allows
using 'optional' fields, but doesn't generate the respective logic
that changes the way of fields serialization. All optional fields
are treated as normal fields in this generator version. This step
allows users to move forward with existing protobuf schemes that
contain optional fields.
Pick-to: 6.6
Task-number: QTBUG-114833
Task-number: QTBUG-114962
Change-Id: I8990325f5fe06470742dc7d607141533bd229c24
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
In the new version of protobuf FileDescriptor::syntax() should not
be used. Instead, protobuf API should be working with both,
proto2 and proto3 syntax.
Task-number: QTBUG-114833
Task-number: QTBUG-114962
Pick-to: 6.6
Change-Id: I86542cfcc0cc247f1e75e6d711e269ff3537f8a4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This approach allows reusing the existing backing target if it's
library and makes step towards plugin-less Qml module.
Pick-to: 6.6
Task-number: QTBUG-115117
Change-Id: I02243d700683ac9e01c1471c3ccccaae71841165
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since the plugin is not exposed by any header file it doesn't make
sense to overcomplicate its export. Use internal cpp macro to export
required plugin. Also this fixes potential issue when export macro
is not provided by user to qtprotobufgen, so the export is not
generated and plugin symbols are simply unaccessible.
Pick-to: 6.6
Change-Id: Ie54cd94eb5ac9e6bb895c02456a6d6d6669a1daf
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This include was removed in the new version of the protobuf,
and it was unused anyway.
Pick-to: 6.6
Change-Id: I5c68f960c031d7f366ab3dc1b690dc9050369975
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
With new version of gRPC, compiler complains about missing include of
the std::set. Move include from .cpp to .h files.
Pick-to: 6.6
Change-Id: Ibfef277598cb9e620ab1b693a42564706302c9cc
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
In case of generating Qt protobuf source code with QML argument,
QML plugin will be created and included into Application build tree.
New QML_URI option is introduced. If there is no package name,
qtprotobufgen must request the QML_URI setting.
Also, it is possible to link several *.proto files to the same plugin
via common URI.
Add nopackage auto-test. Update protobufgen auto-test.
Remove the usage of RESOURCE_PREFIX, replaced by qt_policy.
Task-number: QTBUG-104513
Change-Id: If5c5496245144fa2b499730ab9fdf7d0ee7b2c25
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
QtProtobufgen registers global and local enums in QML context now.
Registration is in qml extension plugin part.
Task-number: QTBUG-104513
Change-Id: Iecbc08d4b915113e7d5753b1f1d24d3c34088ba2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Enable QML flag for qtgrpcgen/qtprotobufgen plugins.
Generated output is updated: QProtobufMessage classes are Q_GADGETs,
such classes can be registered in QML code via QML_VALUE_TYPE macros only.
Also QProtobufMessages are not inherited from QObject class, it means
there is no full qmetaobject system support (no signals!).
Task-number: QTBUG-104513
Change-Id: I18c8f93782884efb8d923843df716ff8284ed8fb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This patch adds support for 'oneof', a union-like type in protobuf,
that need not contain a value, with the following features:
- Setting a oneof field will automatically clear all other
members of the oneof.
- If the parser encounters multiple members of the same oneof
on the wire, only the last member seen is used in the
parsed message.
- A oneof cannot be repeated.
- A oneof cannot contain repeated or map fields.
- If you set a oneof field to the default value (even the default,
such as 0 for an int32 oneof field), the "case" of that oneof
field will be set, and the value will be serialized on the
wire.
Unlike the reference C++ implementation, the Qt implementation of
'oneof' fields adds the 'has<PropertyName>' functions for every
'oneof' member. The protobuf generator generates a Q_PROPERTY for each
member of the 'oneof'; these properties are collectively implemented
as a single class member.
'oneof' fields are represented by the
QtProtobufPrivate::QProtobufOptional class. The class holds the 'oneof'
field number and the value that it contains as QVariant.
A QExplicitSharedDataPointer is used as reference counter, and to copy
and to free the memory of protobuf messages that are stored inside the
nested QVariant as pointers.
The class could also be used to hold 'optional' fields in follow up
commits, but has small overhead since it holds field number, that
is not used by optional fields.
The generated classes also allows reading field number that is
currently stored in the 'oneof' field.
The QtProtobuf::InvalidFieldNumber constant indicates that oneof fields
is uninitialized.
The serialization and deserialization tests use the expected values
from the results of the reference C++ serialization(protobuf version
3.19).
Task-number: QTBUG-103981
Change-Id: Ie4053cb164bba6bc5f14f8cedb34bad62a638c43
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This also means adding another library; the Protobuf Well-Known types
library. No other types added from the collection at the moment.
The Any type is like QVariant or std::any in the sense that it can hold
any type. A small string is embedded along with the Any type upon
serializing. This corresponds to some URL, that can be used for
dynamically looking up definitions of types if wanted
(we don't support this), plus the object name.
We use the embedded object name to verify, upon attempting to
deserialize, that the objects are the same. The function is called
as<T>.
Some users may want a as_unchecked<T>, in the future, where we don't do
this, since different messages may be binary compatible but miss some
fields. And this is fine.
Further, the class also contains the raw bytes of its contained message.
We, quite simply, need to deserialize it to some type when requested.
Implementation consists of a helper-class which uses the "real class" we
generate when serializing or deserializing. At some point they could
potentially be collapsed together to avoid extra overhead. But then
the metadata fields need to be dynamically created or manually
maintained.
When asked to serialize/deserialize the class simply proxies calls to
the "real class" underneath
Fixes: QTBUG-103982
Change-Id: Ie9e833cd30aa58afbd5bdd1a9e9c83bdece6f685
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Alexey Edelev
Dennis Oberst
Tatiana Borisova
Konrad Kujawa
Samuli Piippo
Mårten Nordheim