Max BrunsfeldandJakub Konka
c4d75ea6d5
### Background Zed extensions use WASI to access the file-system. They only have read-write access to one specific folder called their work dir. But extensions do need to be able to *refer* to other arbitrary files on the user's machine. For instance, extensions need to be able to look up existing binaries on the user's `PATH`, and request that Zed invoke them as language servers. Similarly, extensions can create paths to files in the user's project, and use them as arguments in commands that Zed should run. For these reasons, we pass *real* paths back and forth between the host and extensions; we don't try to abstract over the file-system with some virtualization scheme. On Windows, this results in a bit of mismatch, because `wasi-libc` uses *unix-like* path conventions (and thus, so does the Rust standard library when compiling to WASI). ### Change 1 - Fixing `current_dir` In order to keep the extension API minimal, extensions use the standard library function`env::current_dir()` to query the location of their "work" directory. Previously, when initializing extensions, we used the `env::set_current_dir` function to set their work directory, but on Windows, where absolute paths typically begin with a drive letter, like `C:`, the [`wasi-libc` implementation of `chdir`](https://github.com/WebAssembly/wasi-libc/blob/d1793637d8afcdc730408e7b6a19a050c3336ce7/libc-bottom-half/sources/chdir.c#L21) was prepending an extra forward slash to the path, which caused `current_dir()` to return an invalid path. See https://github.com/bytecodealliance/wasmtime/issues/10415 In this PR, I've switched our extension initialization function to *bypass* wasi-libc's `chdir` function, and instead write directly to wasi-libc's private, internal state. This is a bit of a hack, but it causes the `current_dir()` function to do what we want on Windows without any changes to extensions' source code. ### Change 2 - Working around WASI's relative path handling Once `current_dir` was fixed (giving us correct absolute paths on Windows), @kubkon and I discovered that without the spurious leading `/` character, windows absolute paths were no longer accepted by Rust's `std::fs` APIs, because they were now recognized as relative paths, and were being appended to the working directory. We first tried to override the `__wasilibc_find_abspath` function in `wasi-libc` to make it recognize windows absolute paths as being absolute, but that functionality is difficult to override. Eventually @kubkon realized that we could prevent WASI-libc's CWD handling from being linked into the WASM file by overriding the `chdir` function. wasi-libc is designed so that if you don't use their `chdir` function, then all paths will be interpreted as relative to `/`. This makes absolute paths behave correctly. Then, in order to make *relative* paths work again, we simply add a preopen for `.`. Relative paths will match that. ### Next Steps This is a change to `zed-extension-api`, so we do need to update every Zed extension to use the new version, in order for them to work on windows. Release Notes: - N/A --------- Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS and Linux you can download Zed directly or install Zed via your local package manager.
Other platforms are not yet available:
- Windows (tracking issue)
- Web (tracking issue)
Developing Zed
- Building Zed for macOS
- Building Zed for Linux
- Building Zed for Windows
- Running Collaboration Locally
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.