zed-industries/zed · error · anyhow::Error

not yet implemented

Error message

not yet implemented

What it means

The Windows implementation of Platform::path_for_auxiliary_executable is an explicit stub marked todo(windows); it always bails instead of resolving the path of a helper executable installed alongside the app binary. Unlike app_path() (implemented via std::env::current_exe), the auxiliary-executable lookup simply has not been written for the Windows platform.

Source

Thrown at crates/gpui_windows/src/platform.rs:845

            .app_menu_action
            .set(Some(callback));
    }

    fn on_will_open_app_menu(&self, callback: Box<dyn FnMut()>) {
        self.inner
            .state
            .callbacks
            .will_open_app_menu
            .set(Some(callback));
    }

    fn on_validate_app_menu_command(&self, callback: Box<dyn FnMut(&dyn Action) -> bool>) {
        self.inner
            .state
            .callbacks
            .validate_app_menu_command
            .set(Some(callback));
    }

    fn app_path(&self) -> Result<PathBuf> {
        Ok(std::env::current_exe()?)
    }

    // todo(windows)
    fn path_for_auxiliary_executable(&self, _name: &str) -> Result<PathBuf> {
        anyhow::bail!("not yet implemented");
    }

    fn set_cursor_style(&self, style: CursorStyle) {
        let hcursor = load_cursor(style);
        if self.inner.state.current_cursor.get().map(|c| c.0) != hcursor.map(|c| c.0) {
            self.post_message(
                WM_GPUI_CURSOR_STYLE_CHANGED,
                WPARAM(0),
                LPARAM(hcursor.map_or(0, |c| c.0 as isize)),
            );

View on GitHub (pinned to 9d272b0363)

Solutions

1. Implement the method for Windows by resolving siblings of std::env::current_exe() (e.g. current_exe().parent().join(format!("{name}.exe")))
2. Guard the calling feature off Windows with cfg attributes until the stub is implemented
3. Surface a clear 'unsupported on Windows' message to the UI instead of letting the raw bail propagate
4. Check for an existing cross-platform helper (e.g. a paths/util crate) that already resolves auxiliary binaries

Example fix

// before
// todo(windows)
fn path_for_auxiliary_executable(&self, _name: &str) -> Result<PathBuf> {
    anyhow::bail!("not yet implemented");
}

// after
fn path_for_auxiliary_executable(&self, name: &str) -> Result<PathBuf> {
    let path = std::env::current_exe()?
        .parent()
        .ok_or_else(|| anyhow::anyhow!("no parent directory for current exe"))?
        .join(format!("{name}.exe"));
    if path.exists() {
        Ok(path)
    } else {
        anyhow::bail!("auxiliary executable not found: {path:?}")
    }
}

fn supports_auxiliary_executables() -> bool {
    !cfg!(target_os = "windows") // until the todo(windows) stub is implemented
}

cfg:!target_os = "windows"

match platform.path_for_auxiliary_executable(name) {
    Ok(path) => spawn(path),
    Err(e) if e.to_string().contains("not yet implemented") => show_unsupported_message(name),
    Err(e) => return Err(e),
}

When it happens

Trigger: Calling app.path_for_auxiliary_executable(name) in a Windows build — any feature that needs to spawn a bundled helper/server binary (e.g. an LSP or collab server shipped next to the main .exe) hits the stub immediately.

Common situations: Porting a feature that works on macOS/Linux to Windows; calling code that assumes every platform implements the platform trait's full surface; automated tests running on Windows exercising the code path.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

Related errors

• Device lost: {err}
• run request is missing a 'benchmark' block
• Failed to find fxc.exe
• Error when registering clipboard format: {}
• RealtimeAudio priority should use spawn_realtime, not dispat

AI-assisted analysis of zed-industries/zed@9d272b0363 (2026-08-20). Data as JSON: /api/errors/79b07de7a29e596c. Report an issue: GitHub.