| Age | Commit message (Collapse) | Author |
|---|
|
|
|
For EncryptedFile:
- JSON converter bodies moved away to .cpp;
- instead of C-style casts, reinterpret_cast is used to convert from
(const) char* to (const) unsigned char*;
- the size for the target plain text takes into account the case where
the cipher block size can be larger than 1 (after reading
https://www.openssl.org/docs/man1.1.1/man3/EVP_DecryptUpdate.html).
- file decryption is wrapped in #ifdef Quotient_E2EE_ENABLED, to avoid
OpenSSL linking errors when compiling without E2EE.
|
|
That's a better primitive than just exposing SupportedAlgorithms list.
|
|
|
|
A note on switching to QLatin1String for JSON key constants - this is
more concise and barely affects (if at all) runtime performance (padding
each QChar with zeros is trivial for assignment; and comparison can be
done directly with the same performance as for two QStrings).
|
|
Also, removed Q_GADGET macros from key verification events as those
don't seem to do anything (no Q_ENUM/Q_FLAG things, namely).
|
|
|
|
This reverts commit 2cf44607cf0f057e147c2c4fe6dded6c13c58a8a (that was
stupid, honestly).
|
|
Logging categories used by Quotient are not supposed to be exposed
externally, which basically forbids usage of logging in header files.
A more flexible solution would involve moving logging.h to private
headers but Quotient doesn't have that thing yet.
|
|
The result is FTBFS as yet; next commits will fix that, along with a few
other things.
|
|
|
|
|
|
|
|
|
|
Move out current room state to its own class
|
|
Because Apple Clang choked on `explicit(false)`.
|
|
Default construction was only done to support stubbed state in Room
and even that did not really use those, opting to construct an event
from an empty QJsonObject instead. Now that Room doesn't have
stubbed state, default constructors are even less needed.
|
|
|
|
It's too restrictive compared to switchOnType() overloads and doesn't
map to the case with a default value.
|
|
Get rid of that Q_ASSERT() in the middle that only worked in Debug
builds anyway.
|
|
RelatesTo and EventRelation have been two means to the same end in two
different contexts. (Modernised) EventRelation is the one used now both
for ReactionEvent and EventContent::TextContent. The modernisation
mostly boils down to using inline variables instead of functions to
return relation types and switching to QLatin1String from const char*
(because we know exactly that those constants are Latin-1 and
QLatin1String is more efficient than const char* to compare/convert to
QString).
|
|
When internal linkage is necessary, anonymous namespaces fulfil the same
purpose in a better way. See also:
https://stackoverflow.com/questions/4422507/superiority-of-unnamed-namespace-over-static
|
|
It's better than const char* because any interaction between const char*
and QString assumes that const char* contains UTF-8, which is
pessimistic and therefore inefficient; at the same time:
- construction of QString from QLatin1String is extremely fast
(boiling down to padding null bytes)
- "something"_ls is much shorter than QStringLiteral("something")
- "something"_ls produces a direct pointer to the literal at compile
time, using the benefits of raw string literals (deduplication, e.g.)
The library API will also transition to QLatin1String where applicable,
likely in 0.8.
|
|
- Templates and constexpr imply inline
- A function called from a single site better be inlined.
|
|
|
|
It doesn't need all those things inside - order_type alias is no more
in use; operator<() is better outside; QLatin1String is better to
compare against than const char* (because const char* is assumed to be
UTF-8); and TagRecord is really small so it doesn't need const& for
parameters.
|
|
Those are already inherited with 'using'.
|
|
|
|
|
|
On Windows QUOTIENT_API expands to different things depending on whether
the library is built or used. This results in confusing statements (and
MSVC erroring out on them, in some cases - see below - quite
legitimately) not only when the application includes Quotient headers
but also when the application defines custom events and uses
REGISTER_EVENT_TYPE to make them creatable from /sync responses.
To avoid repeated registration when dynamic linking is involved,
EventFactory<>::addMethod() now bluntly looks up the method for this
type in the vector of already registered methods. It would surely be
quicker to use a static variable instead; but since the refreshed API
for addMethod returns a reference to the factory method it's necessary
to do this lookup anyway. Once the primary goal of this branch is
achieved across platforms I might experiment with lighter ways to
register factory methods; for now here's a minimal change to make
the code build on Windows.
|
|
Thanks to Sonar for reminding that constexpr implies inline.
|
|
Pinned message support
|
|
Before all, this fixes the problem with double-initialising of type ids;
it could have been fixed with a smaller change but EventTypeRegistry
is fairly superfluous now when inline variables are a thing and it's
possible to have an extensible registry system using literally pointers
to the memory that are guaranteed to be unique. That being said,
event_type_t is still QLatin1String and not a bare const char* (or
void*), mostly to stay on the safe side when it comes to type
identities: unlike const char*, QLatin1String's are deep-compared,
meaning that matching for switchOnType (former visit) occurs a bit
slower now. This may change in the future; but this is the first step
in getting rid of EventTypeRegistry.
This change means that initializeTypeId is no more needed; also, two
static member functions, typeId() and matrixTypeId(), are being replaced
with a single inline static member variable, TypeId. This commit doesn't
apply that transition across the event types, meaning that you'll get
a pile of warnings when compiling the library. These warnings will be
tackled in further commits within this branch.
|
|
Strictly speaking, EventFactory can be further instantiated if any
client application figures they need a whole new base class for events
and respectively a separate EventFactory specialisation for it.
Where this whole commit started though was a linkage error because I
did not plan to expose Quotient-specific logging categories for linkage
(effectively, usage) from the client code - meanwhile the inline code
of EventFactory uses qDebug(EVENTS), meaning I had to either add
QUOTIENT_API to EVENTS or hide those invocations. This in turn led
to trimming the EventFactory constructor back to trivial implementation
and dropping the guard variable that was supposed to trace duplicate
EventFactory<BaseEventT> objects for the same BaseEventT - with the
reasoning that such situation is not really dangerous (unlike
EventTypeRegistry double-initialisation fiasco, see #413), and at the
same time it can be easily detected in the logs by duplicated factory
method registration messages. And while I was at it, I replaced the
meaningless bool in the return type of EventFactory<>::addMethod with
the slightly more (but still barely) useful reference to the inserted
factory method. One can (in theory) use it now if they need to turn
some event JSON into an object of some specific event type or nullptr
if the event type in the JSON payload doesn't match - but at the same
rate (for now at least) one can call makeIfMatches<EventT>() directly.
With this commit, both Quotest and Quaternion build and link using
either Clang or GCC even under -fvisibility=hidden. However, running
quotest now reproduces #413, which is a matter of event typeId
infrastructure refactoring, coming in further commits.
|
|
This include all (hopefully) classes/structures and functions that have
non-inline definitions, as well as namespaces with Q_NAMESPACE since
those have non-inline (as of Qt 5.15) QMetaObject - for that a new
macro, QUO_NAMESPACE, has been devised to accommodate the lack of
Q_NAMESPACE_EXPORT in Qt before 5.14.
|
|
Fixes a clang-tidy warning.
|
|
|
|
This is a leftover from deferred `name` initialisation that wasn't
needed in the end.
|
|
|
|
|
|
|
|
The former code assumed that EventFactory<> is just a class-level shell
for a bunch of functions and a static data member that only exists to
allow specialisations to occur for the whole group together. On top of
that, setupFactory() and registerEventType() strived to protect this
group from double registration coming from static variables in an
anonymous namespace produced by REGISTER_EVENT_TYPE.
The whole thing is now de-static-ed: resolving the factory now relies
on class-static Event/RoomEvent/StateEventBase::factory variables
instead of factory_t type aliases; and REGISTER_EVENT_TYPE produces
non-static inline variables instead, obviating the need of
registerEventType/setupFactory kludge.
|
|
Objects derived from Event are not room events (in the spec sense) and
never occur in the same arrays as room events; therefore this chaining
has always been superfluous.
|
|
Also: extended quotest to cover member renames, not just user profile renames.
|
|
Co-authored-by: Alexey Rusakov <Kitsune-Ral@users.sf.net>
|
|
|
|
|
|
|
|
|
|
Also, RoomAliasesEvent is to be completely gone after 0.7.
|
