`future_not_send` using excessive amounts of memory causing OOMs on `matrix-sdk` under the next trait solver

[Hywan]

Summary

Hi!

Between nightly-2026-08-21 and nightly-2026-08-22, the memory usage of cargo clippy has increased a lot. It consumes so much memory that Github Actions kills itself when running cargo clippy on our relatively small project (https://github.com/matrix-org/matrix-rust-sdk/).

Reproducer

$ # last nightly (2026-09-28)
$ /usr/bin/time -l rustup run nightly cargo clippy --all-targets --features testing -- -D warnings
[snip]
          3980197888  maximum resident set size

$ # nightly 2026-09-07
$ /usr/bin/time -l rustup run nightly-2026-09-07 cargo clippy --all-targets --features testing -- -D warnings
[snip]
          4348116992  maximum resident set size

$ # nightly 2026-08-22
$ /usr/bin/time -l rustup run nightly-2026-08-22 cargo clippy --all-targets --features testing -- -D warnings
[snip]
          3875028992  maximum resident set size

$ # nightly 2026-08-21
$ /usr/bin/time -l rustup run nightly-2026-08-21 cargo clippy --all-targets --features testing -- -D warnings
[snip]
          1875853312  maximum resident set size

If I put that in a table, in chronological order, with human numbers:

nightly date	maximum resident set size
08-21	1.87Gb
08-22	3.88Gb
09-07	4.34Gb
09-28	3.98Gb

[CommanderStorm]

tagged as ICE because OOM is a similar-ish category, not because this actually ICEs.

The issue needs an mcve to where this actually occurs since matrix-sdk is kind of large in terms of

• which lint/unstable feature and on
• which code is causing this

We fixed a few bugs relating to OOMs recently and have 1-2 PRs open regarding this

• wildcard_imports: infinite loop and unbounded memory growth on macro-generated glob imports #17799
• [Regression 1.98.1] needless_borrows_for_generic_args hangs on Option::filter with a recursive enum #17717

[CommanderStorm]

Firstup, can you change the title of the issue to

future_not_send using excessive amounts of memory causing OOMs on matrix-sdk under the next trait solver

semi-bisected it.
Not entirely sure how you get to 4GB RSS, I get more.. xD

After a bit of an lengthy GDB session, I only see the trait solver and future_not_send being a significant factor in time and memory, which is good.

Looking into this matrix denying clippy::future_not_send in two places only 😆.

$ touch crates/matrix-sdk/src/lib.rs && RUSTC_WRAPPER= /usr/bin/time -f "peak RSS: %M KB" cargo +clippy clippy -p matrix-sdk --lib -F testing -- -D warnings
peak RSS: 17 462 164 KB

But with this small sneaky change to crates/matrix-sdk/src/authentication/matrix/login_builder.rs and crates/matrix-sdk/src/client/mod.rs b/crates/matrix-sdk/src/client/mod.rs you can duckt-tape around this temporarily to unblock you

--- a/crates/matrix-sdk/src/authentication/matrix/login_builder.rs
+++ b/crates/matrix-sdk/src/authentication/matrix/login_builder.rs
@@ -12,7 +12,6 @@
 // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 // See the License for the specific language governing permissions and
 // limitations under the License.
-#![cfg_attr(not(target_family = "wasm"), deny(clippy::future_not_send))]
+// TODO: reenable once <<https://github.com/rust-lang/rust-clippy/issues/17812>> is fixed
+// #![cfg_attr(not(target_family = "wasm"), deny(clippy::future_not_send))]

 #[cfg(feature = "sso-login")]
 use std::future::Future;
diff --git a/crates/matrix-sdk/src/client/mod.rs b/crates/matrix-sdk/src/client/mod.rs
index 7770ce15d..3bdb4c719 100644
--- a/crates/matrix-sdk/src/client/mod.rs
+++ b/crates/matrix-sdk/src/client/mod.rs
@@ -1978,7 +1978,6 @@ impl Client {
     /// client.public_rooms(limit, since, server).await;
     /// # };
     /// ```
-    #[cfg_attr(not(target_family = "wasm"), deny(clippy::future_not_send))]
+    // TODO: reenable once <https://github.com/rust-lang/rust-clippy/issues/17812> is fixed
+    // #[cfg_attr(not(target_family = "wasm"), deny(clippy::future_not_send))]
     pub async fn public_rooms(
         &self,
         limit: Option<u32>,

Unfortunately matrix uses a LOOT of async, which makes the exact cause of this issue a bit hard to debug

I think this makes the trait solver really work for its 💸💸.

I assume this is because we need to prove for every async fn, that the whole returned future is Send. To do this (as I read the code) we need to recursively prove every await that it contains.
Not quite sure why this needs 17GB of RAM to do.

Given how these rough screenshots look, that might be kind of nested I assume.

Clippy could sort of duckt-tape over this issue, by using is_lint_allowed before doing the queries, but I am not entirely convinced that this is the ultimate fix. I opened an PR for this.

At least for matrix-sdk this seems sort of like "the" fix, since they only enable it in a small portion, meaning that we don't actually need to prove everything about that crate...

@blyxyas given your work on query-fication looking into the incremental system, do you have advice that is not just essentially duckt-tape?

[Hywan]

Thanks for digging into this!

[CommanderStorm]

Thanks for reporting 🏓

[blyxyas]

@CommanderStorm try using DHAT the memory profiler (make sure to use --trace-children and go to Clippy's profile)

[Hywan]

Our CI is unblocked. Thank you very much. Happy to help and to report anything you need! We can revert the hotfix anytime and try something else if it helps.