Cargo nightly now checks whether a cfg option exists.
We need to declare the custom
options we use
and fix those that are wrong.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
This makes the public key fields private to ensure that we don't
accidentally swap them out. It also moves the construction of the
subkeys into the master key type.
Since the master/self-signing/user-signing public key types are used for
public user identities as well as for the private key type we have, and
we'd like to sign the public key types it makes sense that the types
itself aren't using an Arc.
Let's instead put the Arc inside the user identity structs.
This will allow us later on to more easily sign the public key types.
This patch removes the notion of `take` vs. `peek` from
`LinkedChunkUpdatesInner` and widens the problem to a more general
approach: `LinkedChunkUpdatesInner` must support multiple readers, not
only two (`take` was the first reader, `peek` was the second reader,
kind of).
Why do we need multiple readers? `LinkedChunkUpdates::take` is
clearly the first reader, it's part of the public API. But the private
API needs to read the updates too, without consuming them, like
`LinkedChunkUpdatesSubscriber`. `peek` was nice for that, but it's
possible to have multiple `LinkedChunkUpdatesSubscriber` at the same
time! Hence the need to widen the approach from 2 readers to many
readers.
This patch introduces a `ReaderToken` to identify readers. The last
indexes are now all stored in a `HashMap<ReaderToken, usize>`. The rest
of the modifications are the consequence of that.
The test `test_updates_take_and_peek` has been entirely rewritten to be
`test_updates_take_and_garbage_collector` where it tests 2 readers and
see how the garbage collector reacts to that.
This patch implements `LinkedChunkUpdates::subscribe` and
`LinkedChunkUpdateSubscriber`, which itself implements `Stream`.
This patch splits `LinkedChunkUpdates` into `LinkedChunkUpdatesInner`,
so that the latter can be shared with `LinkedChunkUpdatesSubscriber`.
This patch adds the `LinkedChunkUpdates::peek` method. This is
a new channel to read the updates without consuming them, like
`LinkedChunkUpdates::take` does.
The complexity is: when do we clear/drop the updates then? We don't
want to keep them in memory forever. Initially `take` was clearing
the updates, but now that we can read them with `peek` too, who's
responsible to clear them? Enter `garbage_collect`. First off,
we already need to maintain 2 index, resp. `last_taken_index` and
`last_peeked_index` so that `take` and `peek` don't return already
returned updates. They respectively know the index of the last update
that has been read. We can use this information to know which updates
must be garbage collected: that's all updates below the two index.
Tadaa. Simple. The only _drawback_ (if it can be considered as such)
is that the garbage collection happens on the next call to `take` or
`peek` (because of the borrow checker). That's not really a big deal in
practise. We could make it happens immediately when calling `take` or
`peek` but it needs more pointer arithmetic and a less straighforward
code.
This patch updates the `LinkedChunk::update_history` field from
a simple `Vec<LinkedChunkUpdate<Item, Gap>>` type to the new
`LinkedChunkUpdates<Item, Gap>` type (note the plural).
This is going to be helpul for the next patches.
Preferring to use "reject" wording rather than "failed to
create/update". The latter can be easily misinterpreted as a failure of
the local client to create an entirely new device from scratch, rather
than refusal to instantiate a new local device representation of an
(invalid) device definition received from the server.
This patch makes the `LinkedChunk::update_history` field optional,
so that it doesn't require the user to drain it to avoid eating the
universe.
The `new` constructor disabled the update history, the
`new_with_update_history` enables it.
This patch is a turn around about the `LinkedChunkListener`. Many
patches have been removed because `LinkedChunkListener` needed to
support I/O, so errors and async code. The whole code was affected by
that, resulting in a complex API. The idea of this patch is to decoupled
this. Here is how.
First off, `LinkedChunkListener` is removed. So it's one less generic
parameter on `LinkedChunk`. It's also one less trait, so less
implementations.
Second, now `LinkedChunk` accumulates/collects all “updates” under the
form of a new enum `LinkedChunkUpdate`. These updates can be read with
`LinkedChunk::updates(&mut self) -> &Vec<LinkedChunkUpdate>`. The reader
can simply read them, or even drain them. The reader is responsible
to handle these updates and to dispatch them in a storage or whatever.
`LinkedChunk` is no longer responsible to do that, removing the need to
support errors and to be async.
Third, the simplification has led to an optimisation by introducing a
new type `LinkedChunkLinks`. The documentation explains what it does
and why it was needed. The benefit of this type is: it doesn't increase
the size of `LinkedChunk`, but it simplifies the code: no more `Arc`,
no more `Mutex` (it was required because with I/O and async), no more
borrow checker trick, and the code stays as safe as before.
This patch removes the `displaydoc` dependency. Why?
1. It creates a warning in rustc nightly:
```
warning: non-local `impl` definition, they should be avoided as they go against expectation
--> crates/matrix-sdk-store-encryption/src/lib.rs:49:17
|
49 | #[derive(Debug, Display, thiserror::Error)]
| ^^^^^^^
|
= help: move this `impl` block outside the of the current constant `_DERIVE_Display_FOR_Error`
= note: an `impl` definition is non-local if it is nested inside an item and may impact type checking outside of that item. This can be the case if neither the trait or the self type are at the same nesting level as the `impl`
= note: one exception to the rule are anon-const (`const _: () = { ... }`) at top-level module and anon-const at the same nesting as the trait or type
= note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <https://github.com/rust-lang/rust/issues/120363>
= note: the derive macro `Display` may come from an old version of the `displaydoc` crate, try updating your dependency with `cargo update -p displaydoc`
= note: `#[warn(non_local_definitions)]` on by default
= note: this warning originates in the derive macro `Display` (in Nightly builds, run with -Z macro-backtrace for more info)
```
2. `thiserror` is already used, which seems to provide a similar issue.
3. That's less dependency, and less proc-macro, which will improve the
compilation time in general.
Also:
- rename `display_name` to `computed_display_name` in several places,
and reflect that change into a few callers
- simplify slightly the `computed_display_name()` method
This is in line with what the other method using sliding sync does. This
wasn't tested before, because this required `filter_by_push_rules()` to
be enabled in the notification client; now that it's the default, the
test revealed the bug, and so it could be fixed.
The builder had only one meaningful method, `filter_by_push_rules`,
which was always called by the applications — and in fact should always
be true. It was designed as an extra method because it was experimental
at the time, but it's stabilized sufficiently that we can enable this
behavior by default now, considering that a notification that is not
wanted by the user shouldn't be kept, to respect their intent. (This is
in the UI crate, which is opinionated, so it's fine to assume such
intents by design.)
