| Age | Commit message (Collapse) | Author |
|---|
|
This is aligned with the non-moving version.
|
|
In a situation where you have an EventPtr that you want to place
somewhere as an `event_ptr_tt<SomeMoreSpecificEventType>` you have to
carefully check that the stored event is actually of
SomeMoreSpecificType and if it is, release() that event pointer,
downcast, and re-wrap it into that new event_ptr_tt - or, as can be seen
from the diff here, re-loadEvent() from JSON, which is simpler but
inefficient. To help clients, and the library, eventCast() can now
accept an rvalue smart pointer and do all the necessary things with it.
|
|
|
|
|
|
The last commit broke it.
|
|
The upcoming event type infrastructure finally helps to detect those
omissions more or less reliably (for event types only though).
|
|
|
|
This introduces enumTo/FromJsonString() and flagTo/FromJsonString(),
four facility functions to simplify conversion between C++ enums and
JSON, and refactors a couple of places where it's useful.
|
|
JSON conversions are moved out of the class, obviating the need to
define the plain data constructor and gaining default-constructibility
along the way - previously the default constructor was preempted
by user-defined ones.
|
|
EncryptionEvent was marked as Q_GADGET only for the sake of defining
EncryptionType inside of it as Q_ENUM, with aliases also available under
Quotient:: and EncryptionEventContent. This is a legacy from
pre-Q_ENUM_NS times. However, event types are not really made to be
proper Q_GADGETs: Q_GADGET implies access by value or reference
but event types are uncopyable for the former and QML is ill-equipped
for the latter.
This commit moves EncryptionType definition to where other such
enumerations reside - on the namespace level in quotient_common.h; and
the other two places are now deprecated; and EncryptionEvent is no more
Q_GADGET.
With fromJson/toJson refactored in the previous commit there's no more
need to specialise JsonConverter<>: specialising fromJson() is just
enough.
Moving EncryptionType to quotient_common.h exposed the clash
of two Undefined enumerators (in RoomType and EncryptionType),
warranting both enumerations to become scoped (which they ought to be,
anyway). And while we're at it, the base type of enumerations is
specified explicitly, as MSVC apparently uses a signed base type (int?)
by default, unlike other compilers, and the upcoming enum converters
will assume an unsigned base type.
Finally, using fillFromJson() instead of fromJson() in
the EncryptionEventContent constructor allowed to make default values
explicit in the header file, rather than buried in the initialisation
code.
|
|
fromJson() is generalised to accept any JSON-like type while passing
QJsonObject to JsonConverter<>::load (instead of doLoad). This allows to
(still) rely on JsonConverter<> as a customisation point while providing
an opportunity to overload fromJson for custom types in a pointed way
(specifically, by providing the overload for
`fromJson(const QJsonObject&)`), instead of having to go with full-blown
JsonConverter<> specialisation. This will be used in a further commit
to simplify ReceiptEvent definition.
Using if constexpr in combination with constraints (`requires()`) -
the first such case in Quotient codebase - allowed to put the entire
logic in a single JsonConverter<>::load() body instead of having a
facility JsonExporter<> class for SFINAE.
Aside from that, fromJson<QJsonValue, QJsonValue> is entirely dropped
because it's not supposed to be used that way (it's no-op after all);
reflecting that, Event::unsignedPart() and Event::contentPart() no more
default to QJsonValue as the expected return type, you have to
explicitly provide the type instead (and as one can see from the changes
in the commit, it's actually better that way since it's better
to validate the value inside JSON - e.g. check QString or QJsonObject
for emptiness - than the QJsonValue envelope which may still wrap
an empty value).
toJson() is also generalised, replacing 3 functions with one that has
a constexpr if to discern between two kinds of types.
|
|
[skip ci]
|
|
Dropping yet another translation unit.
|
|
Apple Clang doesn't have those yet.
|
|
...thanks to C++20 awesomeness. A notable change is that
wrap_in_function() (and respectively function_traits<>::function_type)
and fn_return_t alias are gone. The former are no more needed because
connectUntil/connectSingleShot no more use std::function. The latter
has been relatively underused and with the optimisation of switchOnType
hereby, could be completely replaced with std::invoke_result_t.
Rewriting connect* functions using constexpr and auto parameters made
the implementation 30% more compact and much easier to understand
(though still with a couple of - now thoroughly commented - tricky
places). Dropping std::function<> from it may also bring some (quite
modest, likely) performance benefits.
|
|
|
|
Now there's only 1 instead of 5 lookups of the same EncryptionEvent,
and the code is shorter.
|
|
In keyverificationevent.*, this massively shortens repetitive getter
definitions; the remaining few non-trivial ones are moved to
keyverificationevent.h, dropping the respective .cpp file and therefore
the dedicated translation unit. In roomkeyevent.h, it's just shorter.
|
|
Also: leave a link at the place in the spec with power level defaults
to make it clear they are not invented out of thin air.
|
|
|
|
|
|
...instead of tucking the template in filesourceinfo.cpp where it surely
will be forgotten.
|
|
This pertains to QUO_IMPLICIT and DECL_DEPRECATED_ENUMERATOR - both can
be used with no connection to Qt meta-type system (which is what
quotient_common.h is for).
|
|
make_array() has been introduced to cover for shortcomings on macOS and
Windows. These shortcomings are no more there, so we can just use the
standardrlibrary.
|
|
Functions (Room::Private::)createOlmSession, payloadForUserDevice
and sendRoomKeyToDevices don't have a lot to do with the given Room
object but deal with quite a few things stored in Connection. This
commit moves them to Connection::Private, exposing
sendSessionKeyToDevices (the new name for sendRoomKeyToDevices) in
Connection so that Room could call it from Room::P::sendMegolmSession().
While moving these over, a few additional things were adjusted:
- more functions marked as const
- a few functions could be moved now from Connection
to Connection::Private
- false slots in Connection (such as picklingMode) are moved out of
the slots block
- keys.yml in Matrix CS API definitions has been adjusted to match
the real structure of `/claim` response (see quotient-im/matrix-spec
repo); csapi/keys.h has been regenerated accordingly.
|
|
|
|
These are not operations on EncryptedFileMetadata but rather on
a combination of EncryptedFileMetadata and ciphertext. If C++ had
multimethods these could be bound to such a combination.
|
|
Besides having a misleading name (and it goes back to the spec),
EncryptedFile under `file` key preempts the `url` (or `thumbnail_url`)
string value so only one of the two should exist. This is a case for
using std::variant<> - despite its clumsy syntax, it can actually
simplify and streamline code when all the necessary bits are in place
(such as conversion to JSON and getting the common piece - the URL -
out of it). This commit replaces `FileInfo::url` and `FileInfo::file`
with a common field `source` of type `FileSourceInfo` that is an alias
for a variant type covering both underlying types; and `url()` is
reintroduced as a function instead, to allow simplified access
to whichever URL is available inside the variant.
Oh, and EncryptedFile is EncryptedFileMetadata now, to clarify that it
does not represent the file payload itself but rather the data necessary
to obtain that payload.
|
|
Co-authored-by: Alexey Rusakov <Kitsune-Ral@users.sf.net>
|
|
The ciphertext for AES CTR is exactly as large as the plaintext (not
necessarily a multiple of the blocksize!). By truncating the ciphertext,
we do not send bytes that will be decrypted to gibberish.
As a side node, we probably do not need to initialize the ciphertext
buffer larger than the plaintext size at all, but the OpenSSL docs are a
bit vague about that.
|
|
|
|
Co-authored-by: Alexey Rusakov <Kitsune-Ral@users.sf.net>
|
|
Co-authored-by: Alexey Rusakov <Kitsune-Ral@users.sf.net>
|
|
|
|
|
|
|
|
|
|
|
|
Mainly driven by clang-tidy and SonarCloud warnings (sadly, SonarCloud
doesn't store historical reports so no link can be provided here).
|
|
See https://github.com/matrix-org/matrix-spec/pull/1054.
# Conflicts:
# lib/events/callanswerevent.cpp
# lib/events/callanswerevent.h
|
|
|
|
To streamline adding of simple getters of content parts.
|
|
QPair is giving way to its STL counterpart, becoming its alias in Qt 6.
|
|
|
|
This macro was defined in accountdataevents.h but adding one more
parameter (base class) makes it applicable to pretty much any event
with the content that has one key-value pair (though state events
already have a non-macro solution in the form of
`StateEvent<EventContent::SingleKeyValue>`). Now CustomEvent definition
in quotest.cpp can be replaced with a single line.
|
|
Not that it was very important, as the two are basically the same thing
(and matrixTypeId() is about to be obsoleted); but formally basicJson()
is supposed to get the former, not the latter.
|
|
This makes it easier and more intuitive to build a minimal JSON payload
for a given event type. A common basicJson() call point is also
convenient in template contexts (see next commits).
|
|
EventContent::Base has been made primarily for the sake of dynamic
polymorphism needed within RoomMessageEvent content (arguably, it might
not be really needed even there, but that's a bigger matter for another
time). When that polymorphism is not needed, it's easier for reading
and maintenance to have toJson() member function (or even specialise
JsonConverter<> outside of the content structure) instead of deriving
from EC::Base and then still having fillJson() member function. This
commit removes EventContent::Base dependency where it's not beneficial.
|
|
Main changes:
1. Base::fillJson() gets a QJsonObject& instead of QJsonObject* - c'mon,
there's nothing inherently wrong with using an lvalue reference for a
read-write parameter.
2. UrlWithThumbnailContent merged into UrlBasedContent. The original
UrlBasedContent was only used to produce a single class,
AudioContent, and even that can logically have a thumbnail even if
the spec doesn't provision that. And there's no guarantee even for
visual content (ImageContent, e.g.) to have thumbnail data; the
fallback is already tested.
3. toInfoJson is converted from a template to a couple of overloads
that supersede fillInfoJson() member functions in FileInfo/ImageInfo.
These overloads are easier on the eye; and clang-tidy no more warns
about ImageInfo::fillInfoJson() shadowing FileInfo::fillInfoJson().
4. Now that UrlWithThumbnail is gone, PlayableContent can directly
derive from UrlBasedContent since both its specialisations use it.
5. Instead of FileInfo/ImageInfo, fillInfoJson() has been reinvented
within UrlBasedContent so that, in particular, PlayableContent
wouldn't need to extract 'info' subobject and then roll it back
inside the content JSON object.
|
|
|
