Notably, split the code into smaller functions, and revamp the high-level signatures so the individual handle_ functions don't take a bazillion arguments.
The reports now include the final state as well as the set of operations to run, so we can really debug all the steps just from looking at a rageshake.
When we're removing or inserting any day divider, we're also updating the offset, so that subsequent operations happen at the right positions.
The previous code made the error to clamp the offset when assigning it, instead of letting it be "out of bounds" and clamping the uses, which is
the correct way to implement this.
The test has been failing with a timeout recently, several time. Let's see if it was a fluke caused by the low threshold (because the server might be
busy handling other requests from other tests), or an actual issue.
It appears that tarpaulin complains if the symbol information is stripped from
the binary, and as of Rust 1.77, `debug=0` causes Cargo to strip all debug
info.
To fix this, set `debug=1`.
This patch renames `ChunkIdentifierGenerator::generate_next` to `next.
This patch also simplifies a `.saturating_add(1)` to a simple `+ 1`,
which is fine because we have checked for overflow just before.
Up until uniffi 0.26 it was not possible to send objects
across the boundary unless they were wrapped in an `Arc<>`,
see https://github.com/mozilla/uniffi-rs/pull/1672
The bindings generator used in complement-crypto only supports
up to uniffi 0.25, meaning having a function which returns objects
ends up erroring with:
```
error[E0277]: the trait bound `TaskHandle: LowerReturn<UniFfiTag>` is not satisfied
--> bindings/matrix-sdk-ffi/src/room_directory_search.rs:109:10
|
109 | ) -> TaskHandle {
| ^^^^^^^^^^ the trait `LowerReturn<UniFfiTag>` is not implemented for `TaskHandle`
|
= help: the following other types implement trait `LowerReturn<UT>`:
<bool as LowerReturn<UT>>
<i8 as LowerReturn<UT>>
<i16 as LowerReturn<UT>>
<i32 as LowerReturn<UT>>
<i64 as LowerReturn<UT>>
<u8 as LowerReturn<UT>>
<u16 as LowerReturn<UT>>
<u32 as LowerReturn<UT>>
and 133 others
error[E0277]: the trait bound `TaskHandle: LowerReturn<_>` is not satisfied
--> bindings/matrix-sdk-ffi/src/room_directory_search.rs:82:1
|
82 | #[uniffi::export(async_runtime = "tokio")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `LowerReturn<_>` is not implemented for `TaskHandle`
|
= help: the following other types implement trait `LowerReturn<UT>`:
<bool as LowerReturn<UT>>
<i8 as LowerReturn<UT>>
<i16 as LowerReturn<UT>>
<i32 as LowerReturn<UT>>
<i64 as LowerReturn<UT>>
<u8 as LowerReturn<UT>>
<u16 as LowerReturn<UT>>
<u32 as LowerReturn<UT>>
and 133 others
```
This PR wraps the offending function in an `Arc<>` to make it uniffi 0.25 compatible,
which unbreaks complement crypto.
`TryFrom` and `TryInto` are imported redundantly. They are already
defined in `core::prelude::rust_2021` which is automatically imported.
This is generating warnings on my side. This patch fixes that.
This patch makes `ChunkIdentifierGenerator::generate_next` to panic
if there is no more identifiers available. It was previously returning
a `Result` but we were doing nothing with this `Result` except
`unwrap`ping it. To simplify the API: let's panic.
As suggested in https://github.com/matrix-org/matrix-rust-sdk/
pull/3251#discussion_r1532103818 by Poljar, it is possible that the
value of the atomic changes between the `fetch_add` and the `load` (if
and only if it is used in a concurrency model, which is not the case
right now, but anyway… better being correct now!). The idea is not
`load` but repeat the addition manually to compute the “current” value.
Imagine we have this linked chunk:
```rust
assert_items_eq!(linked_chunk, ['a'] [-] ['b', 'c'] ['d', 'e', 'f']);
```
Before the patch, when we were running:
```rust
let position_of_d = linked_chunk.item_position(|item| *item == 'd').unwrap();
linked_chunk.insert_gap_at((), position_of_d)?;
```
it was taking `['d', 'e', 'f']` to split it at index 0, so `[]` + `['d',
'e', 'f']`, and then was inserting a gap in between, thus resulting
into:
```rust
assert_items_eq!(linked_chunk, ['a'] [-] ['b', 'c'] [] [-] ['d', 'e', 'f']);
```
The problem is that it creates a useless empty chunk. It's a waste of
space, and rapidly, of computation. When used with `EventCache`, this
problem occurs every time a backpagination occurs (because it executes
a `replace_gap_at` to insert the new item, and then executes a
`insert_gap_at` if the backpagination contains another `prev_batch`
token).
With this patch, the result of the operation is now:
```rust
assert_items_eq!(linked_chunk, ['a'] [-] ['b', 'c'] [-] ['d', 'e', 'f']);
```
The `assert_items_eq!` macro has been updated to be able to assert
empty chunks. The `test_insert_gap_at` has been updated to test all
edge cases.
A couple of small changes that allow us to drop locks that would
otherwise persist when running the tests over the MemoryStore, and some
documentation comments for assertions to make it easier to spot which
assertion failed, even though we are inside a macro.
Backing up room keys isn't part of the outgoing requests processing
loop, instead the user is supposed to have a separate loop calling
`BackupMachine::backup()`.
Benjamin Bouvier