iced-rs/iced · critical
not implemented
Error message
not implemented
What it means
iced_futures ships pluggable async executor backends (tokio, smol, thread-pool) behind Cargo features. When none is enabled, `backend::Executor` resolves to the null backend: `spawn` silently drops futures and `block_on` is a stub that panics with `unimplemented!()`. The panic fires the first time anything tries to drive a future to completion on that executor.
Source
Thrown at futures/src/backend/null.rs:17
//! A backend that does nothing!
use crate::MaybeSend;
/// An executor that drops all the futures, instead of spawning them.
#[derive(Debug)]
pub struct Executor;
impl crate::Executor for Executor {
fn new() -> Result<Self, futures::io::Error> {
Ok(Self)
}
fn spawn(&self, _future: impl Future<Output = ()> + MaybeSend + 'static) {}
#[cfg(not(target_arch = "wasm32"))]
fn block_on<T>(&self, _future: impl Future<Output = T>) -> T {
unimplemented!()
}
}
pub mod time {
//! Listen and react to time.
}
View on GitHub (pinned to 2cffa99b39)
Solutions
- Enable an executor backend feature on iced_futures: `iced_futures = { features = ["tokio"] }` (or "smol" / "thread-pool")
- If you use the iced facade crate, enable its "tokio" (or "smol") feature instead of re-declaring iced_futures with default-features = false
- Verify the dependency graph keeps an executor enabled: `cargo tree -i iced_futures -f "{p} {f}"`
- If you must stay executor-free, drive futures with your own runtime and never call block_on on the null Executor
Example fix
// before
iced_futures = { version = "0.13", default-features = false }
// after
iced_futures = { version = "0.13", default-features = false, features = ["tokio"] } Defensive patterns
Strategy: fallback
Validate before calling
# CI sanity check: confirm an executor feature survives the dependency graph
cargo tree -i iced_futures -f '{p} {f}' | grep -E 'tokio|smol|thread-pool' || echo 'NO EXECUTOR FEATURE ENABLED' Try / catch
let outcome = std::panic::catch_unwind(|| executor.block_on(app_future));
if outcome.is_err() {
eprintln!("block_on panicked: is an iced_futures executor feature (tokio/smol/thread-pool) enabled?");
std::process::exit(101);
} Prevention
- Always declare an executor feature explicitly when using iced_futures with default-features = false
- Prefer the iced facade crate's default tokio backend rather than hand-rolling the dependency
- Add a CI check that the built feature set keeps tokio/smol/thread-pool on for iced_futures
- Treat futures silently not running as the early symptom of the null backend — investigate before block_on panics
When it happens
Trigger: Calling `Executor::block_on` (directly, or via an iced entry point that runs the event loop to completion) when iced_futures is compiled with `default-features = false` and no `tokio`/`smol`/`thread-pool` feature. Note that on the null backend `spawn` is also a silent no-op, so futures never running is the earlier symptom.
Common situations: Setting default-features = false to slim down iced and forgetting to re-enable an executor; version upgrades that renamed or re-gated executor features; a workspace where another crate's dependency on iced_futures strips optional features via unification; native code accidentally calling the cfg(not(wasm32)) block_on path.
Related errors
- Encode input message
- Encode input message
- lock font name cache
- Downcast widget state
- Write application metadata
AI-assisted analysis of iced-rs/iced@2cffa99b39 (2026-08-16).
Data as JSON: /api/errors/24a9c01241be893c.
Report an issue: GitHub.