| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
QCoreApplication::processEvents() is well-known to be a _wrong_ solution
to the unresponsive UI problem; despite that, connection.cpp has long
had that call to let UI update itself while processing bulky room
updates (mainly from the initial sync). This commit finally fixes this,
after an (admittedly rare) race condition has been hit, as follows:
0. Pre-requisite: quotest runs all the tests and is about to leave
the room; there's an ongoing sync request.
1. Quotest calls /leave
2. Sync returns, with the batch of _several_ rooms (that's important)
3. The above code handles the first room in the batch
4. processEvents() is called, just in time for the /leave response.
5. The /leave response handler in quotest ends up calling
Connection::logout() (processEvents() still hasn't returned).
6. Connection::logout() calls abandon() on the ongoing SyncJob,
pulling the rug from under onSyncSuccess()/consumeRoomData().
7. processEvents() returns and the above code proceeds to the next
room - only to find that the roomDataList (that is a ref to
a structure owned by SyncJob), is now pointing to garbage.
Morals of the story:
1. processEvents() effectively makes code multi-threaded: one flow is
suspended and another one may run _on the same data_. After the first
flow is resumed, it cannot make any assumptions regarding which data
the second flow touched and/or changed.
2. The library had quite a few cases of using &&-refs, avoiding even
move operations but also leaving ownership of the data with the
original producer (SyncJob). If the lifetime of that producer ends
too soon, those refs become dangling.
The fix makes two important things, respectively:
2. Ownership of room data is now transfered to the processing side,
the moment it is scheduled (see below), in the form of moving
into a lambda capture.
1. Instead of processEvents(), processing of room data is scheduled
via QMetaObject::invokeMethod(), uncoupling the moment when the
data was received in SyncJob from the moment they are processed
in Room::updateData() (and all the numerous signal-slots it calls).
Also: Room::baseStateLoaded now causes Connection::loadedRoomState, not
the other way round - this is more natural and doesn't need Connection
to keep firstTimeRooms map around.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The result is FTBFS as yet; next commits will fix that, along with a few
other things.
|
|
|
|
|
|
There are two important aspects here:
- Introducing Room::setState(evtType, stateKey, contentJson). These
components are ultimately what is getting sent to the homeserver,
so it makes sense to expose a respective `setState()` overload.
Unlike setState(event) the new overload can be Q_INVOKABLE.
- Room::setState() is no more const. Although it doesn't cause any
changes in Room class (and only transient changes in Room::Private),
it ultimately initiates a change in the room state, so calling it
const has always been a bit of hypocrisy. If you relied on that, you
most likely do something wrong (see the fix to User::rename()
in this very commit for a simple example of such wrongness).
Also: the backend is simplified by calling the original templated
Room::setState() instead of calling Room::Private::requestSetState()
that does exactly the same thing.
|
|
This class is called to provide an arbitrary snapshot of a room state;
as the first step, Room::currentState() returns an instance of this
class that stores, well, the current state. Implelementation-wise it's
the same hash map of two-part state event keys to const event pointers;
however, RoomStateView provides additional operations:
- get(), that deprecates Room::getCurrentState(), returns a pointer to
a particular event if the current state has it. Unlike the original
method, the pointer returned from this one can be nullptr; this is
done to get rid of stubbed state events that have to be created
everytime a "state miss" occurred (i.e., when getCurrentState()
does not find an existing event in the current state).
- eventsOfType() - this is a new place for Room::stateEventsOfType()
introduced recently.
- query() - this is a way to specify a piece of the state content that
you need to retrieve by passing a member function or a function object
that retrieves it. That is especially convenient with member functions
of the event class; just pass the pointer to this member function,
and query() will parse the event type it has to retrieve out of it and
call that member function on the event object. Returns an Omittable<>;
if the respective piece of state doesn't exist, you'll get
`Quotient::none` (the same as `std::nullopt`).
- queryOr() - the same but with the fallback value; instead of an
Omittable<>, the fallback value will be returned if the needed event
is not found.
|
|
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).
|
|
Use 'auto'; range-for instead of an iterator loop.
|
|
`Room::Change` has been changed to be an enum class recently; and it's values are no more suffixed with `Change`.
|
|
|
|
|
|
Co-authored-by: Alexey Rusakov <Kitsune-Ral@users.sf.net>
|
|
|
|
|
|
|
|
messages
|
|
|
|
|
|
|
|
It has not much to do with the Visitor design pattern; also,
std::visit() has different conventions on the order of parameters.
|
|
|
|
|
|
|
|
Co-authored-by: Alexey Rusakov <Kitsune-Ral@users.sf.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
decryption, handling of encrypted redactions and replies
|
|
|
|
|
|
|
|
|
|
|
