gfx-rs/wgpu · critical

No context available. You need to enable one of wgpu's backe

Error message

No context available. You need to enable one of wgpu's backend feature build flags.

What it means

This panic comes from the `Deref` implementation of the dispatch enums generated by `dispatch_types!` (wgpu/src/dispatch.rs:902). When wgpu is compiled with NEITHER the `wgpu_core` NOR the `webgpu` feature, every match arm is cfg'd out, so dereferencing any dispatch handle (or calling any trait method on it) has no variant to return and panics with 'No context available...'. wgpu requires at least one backend feature to function.

Source

Thrown at wgpu/src/dispatch.rs:902

            fn from(value: $webgpu_type) -> Self {
                Self::WebGPU(value)
            }
        }

        impl core::ops::Deref for $name {
            type Target = dyn $interface;

            #[inline]
            fn deref(&self) -> &Self::Target {
                match self {
                    #[cfg(wgpu_core)]
                    Self::Core(value) => value,
                    #[cfg(webgpu)]
                    Self::WebGPU(value) => value,
                    #[cfg(custom)]
                    Self::Custom(value) => value.deref(),
                    #[cfg(not(any(wgpu_core, webgpu)))]
                    _ => panic!("No context available. You need to enable one of wgpu's backend feature build flags."),
                }
            }
        }

        explicit_send_sync_impl!($name);
    };
    (
        mut type $name:ident: $interface:ident = $core_type:ident,$webgpu_type:ident,$custom_type:ident
    ) => {
        #[derive(Debug, PartialEq, Eq, PartialOrd, Ord, Hash)]
        pub enum $name {
            #[cfg(wgpu_core)]
            Core($core_type),
            #[cfg(webgpu)]
            WebGPU($webgpu_type),
            #[allow(clippy::allow_attributes, private_interfaces)]
            #[cfg(custom)]
            Custom($custom_type),

View on GitHub (pinned to 3e11ff59bf)

Solutions

  1. Enable a backend feature in Cargo.toml: `wgpu = { features = ["wgpu_core"] }` (or `"webgpu"` for WASM)
  2. If using `default-features = false`, re-enable defaults or explicitly list `wgpu_core`/`webgpu`
  3. Verify with `cargo tree -e features -p wgpu` or `cargo metadata` that a backend feature is active in the resolved build
  4. If a fully stubbed build is intended, guard all wgpu usage behind `#[cfg(any(wgpu_core, webgpu))]` so the panicking code is never compiled/called

Example fix

// before (Cargo.toml)
wgpu = { version = "24", default-features = false }
// after (Cargo.toml)
wgpu = { version = "24", default-features = false, features = ["wgpu_core"] }
Defensive patterns

Strategy: validation

Validate before calling

// Cargo.toml — verify a backend feature is enabled before building
// wgpu = { features = ["wgpu_core"] }
// CI check:
// cargo metadata | jq '.packages[] | select(.name=="wgpu")'

Try / catch

// Panic cannot be caught; guard at build time instead
#[cfg(not(any(feature = "wgpu_core", feature = "webgpu")))]
compile_error!("Enable the wgpu_core or webgpu feature");

Prevention

When it happens

Trigger: Compiling the `wgpu` crate with all backend feature flags disabled (no `wgpu_core`, no `webgpu`), then constructing or using any wgpu resource (device, bind group, etc.) whose Deref hits the catch-all arm — e.g. running benches/benches/wgpu-benchmark/bind_groups.rs against a feature-less wgpu build.

Common situations: Dependending on wgpu with `default-features = false` and forgetting to add a backend feature; minimal/embedded builds trimming features; CI matrix configs that accidentally drop backend features; custom-backend setups that enable only `custom` plus cfg conditions not matching (though `custom` alone avoids this arm).

Related errors


AI-assisted analysis of gfx-rs/wgpu@3e11ff59bf (2026-09-03). Data as JSON: /api/errors/44e911008106c870. Report an issue: GitHub.