Fixes an issue that caused Windows to fail when removing extension's
directories, as Zed had never stop any related processes.
Now:
* Zed shuts down and waits until the end when the language servers are
shut down
* Adds `impl Drop for WasmExtension` where does
`self.tx.close_channel();` to stop a receiver loop that holds the "lock"
on the extension's work dir.
The extension was dropped, but the channel was not closed for some
reason.
* Does more unregistration to ensure `Arc<WasmExtension>` with the `tx`
does not leak further
* Tidies up the related errors which had never reported a problematic
path before
Release Notes:
- N/A
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Smit <smit@zed.dev>
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
Other small patch to reduce allocations.
`.iter().cloned().collect()` calls `Clone` per element, whereas
`.into_iter().collect()` preallocates the `Vec`.
The Zed repo for example has up to 1700 packages on some build
configurations, meaning this change theoretically saves up to 1699
allocations. It's likely the compiler has already optimized this away,
but it's good to be explicit.
Release Notes:
- N/A
This PR introduces support for a `--user-data-dir` CLI flag to override
Zed's data directory and proposes renaming `support_dir` to `data_dir`
for better cross-platform clarity. It builds on the discussion in #25349
about custom data directories, aiming to provide a flexible
cross-platform solution.
### Changes
The PR is split into two commits:
1. **[feat(cli): add --user-data-dir to override data
directory](https://github.com/zed-industries/zed/pull/26886/commits/28e8889105847401e783d1739722d0998459fe5a)**
2. **[refactor(paths): rename support_dir to data_dir for cross-platform
clarity](https://github.com/zed-industries/zed/pull/26886/commits/affd2fc606b39af1b25432a688a9006229a8fc3a)**
### Context
Inspired by the need for custom data directories discussed in #25349,
this PR provides an immediate implementation in the first commit, while
the second commit suggests a naming improvement for broader appeal.
@mikayla-maki, I’d appreciate your feedback, especially on the rename
proposal, given your involvement in the original discussion!
### Testing
- `cargo build `
- `./target/debug/zed --user-data-dir ~/custom-data-dir`
Release Notes:
- Added --user-data-dir CLI flag
---------
Signed-off-by: Marko Kungla <marko.kungla@gmail.com>
This adds a "workspace-hack" crate, see
[mozilla's](https://hg.mozilla.org/mozilla-central/file/3a265fdc9f33e5946f0ca0a04af73acd7e6d1a39/build/workspace-hack/Cargo.toml#l7)
for a concise explanation of why this is useful. For us in practice this
means that if I were to run all the tests (`cargo nextest r
--workspace`) and then `cargo r`, all the deps from the previous cargo
command will be reused. Before this PR it would rebuild many deps due to
resolving different sets of features for them. For me this frequently
caused long rebuilds when things "should" already be cached.
To avoid manually maintaining our workspace-hack crate, we will use
[cargo hakari](https://docs.rs/cargo-hakari) to update the build files
when there's a necessary change. I've added a step to CI that checks
whether the workspace-hack crate is up to date, and instructs you to
re-run `script/update-workspace-hack` when it fails.
Finally, to make sure that people can still depend on crates in our
workspace without pulling in all the workspace deps, we use a `[patch]`
section following [hakari's
instructions](https://docs.rs/cargo-hakari/0.9.36/cargo_hakari/patch_directive/index.html)
One possible followup task would be making guppy use our
`rust-toolchain.toml` instead of having to duplicate that list in its
config, I opened an issue for that upstream: guppy-rs/guppy#481.
TODO:
- [x] Fix the extension test failure
- [x] Ensure the dev dependencies aren't being unified by Hakari into
the main dependencies
- [x] Ensure that the remote-server binary continues to not depend on
LibSSL
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
There's still a bit more work to do on this, but this PR is compiling
(with warnings) after eliminating the key types. When the tasks below
are complete, this will be the new narrative for GPUI:
- `Entity<T>` - This replaces `View<T>`/`Model<T>`. It represents a unit
of state, and if `T` implements `Render`, then `Entity<T>` implements
`Element`.
- `&mut App` This replaces `AppContext` and represents the app.
- `&mut Context<T>` This replaces `ModelContext` and derefs to `App`. It
is provided by the framework when updating an entity.
- `&mut Window` Broken out of `&mut WindowContext` which no longer
exists. Every method that once took `&mut WindowContext` now takes `&mut
Window, &mut App` and every method that took `&mut ViewContext<T>` now
takes `&mut Window, &mut Context<T>`
Not pictured here are the two other failed attempts. It's been quite a
month!
Tasks:
- [x] Remove `View`, `ViewContext`, `WindowContext` and thread through
`Window`
- [x] [@cole-miller @mikayla-maki] Redraw window when entities change
- [x] [@cole-miller @mikayla-maki] Get examples and Zed running
- [x] [@cole-miller @mikayla-maki] Fix Zed rendering
- [x] [@mikayla-maki] Fix todo! macros and comments
- [x] Fix a bug where the editor would not be redrawn because of view
caching
- [x] remove publicness window.notify() and replace with
`AppContext::notify`
- [x] remove `observe_new_window_models`, replace with
`observe_new_models` with an optional window
- [x] Fix a bug where the project panel would not be redrawn because of
the wrong refresh() call being used
- [x] Fix the tests
- [x] Fix warnings by eliminating `Window` params or using `_`
- [x] Fix conflicts
- [x] Simplify generic code where possible
- [x] Rename types
- [ ] Update docs
### issues post merge
- [x] Issues switching between normal and insert mode
- [x] Assistant re-rendering failure
- [x] Vim test failures
- [x] Mac build issue
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Joseph <joseph@zed.dev>
Co-authored-by: max <max@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
Co-authored-by: Mikayla Maki <mikaylamaki@Mikaylas-MacBook-Pro.local>
Co-authored-by: Mikayla <mikayla.c.maki@gmail.com>
Co-authored-by: joão <joao@zed.dev>
This PR overhauls extension registration in order to make it more
modular.
The `extension` crate now contains an `ExtensionHostProxy` that can be
used to register various proxies that the extension host can use to
interact with the rest of the system.
There are now a number of different proxy traits representing the
various pieces of functionality that can be provided by an extension.
The respective crates that provide this functionality can implement
their corresponding proxy trait in order to register a proxy that the
extension host will use to register the bits of functionality provided
by the extension.
Release Notes:
- N/A
This PR updates the `ExtensionLspAdapter` to go through the `Extension`
trait for interacting with extensions rather than going through the
`WasmHost` directly.
Release Notes:
- N/A
This PR extracts the `ExtensionIndexedDocsProvider` implementation to
the `indexed_docs` crate.
To achieve this, we introduce a new `Extension` trait that provides an
abstracted interface for calling an extension. This trait resides in the
`extension` crate, which has minimal dependencies and can be depended on
by other crates, like `indexed_docs`.
We're then able to implement the `ExtensionIndexedDocsProvider` without
having any knowledge of the Wasm-specific internals of the extension
system.
Release Notes:
- N/A
This contains the main changes to the extensions crate from #20049. The
primary goal here is removing dependencies that we can't include on the
remote.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Marshall <marshall@zed.dev>
This PR fixes an issue where crate names that included `-`s would not
work properly when indexing them with rustdoc, due to the output
directories using `_` instead of `-`.
Release Notes:
- N/A
This PR promotes package suggestions to a first-class concept on the
`IndexedDocsProvider` trait.
This will allow any implementer of `IndexedDocsProvider` to provide a
list of package names to suggest for use with `/docs`.
For the docs.rs provider we use the 250 most popular Rust crates (as
identified [here](https://lib.rs/std)), and for the rustdoc provider we
use the packages in the Cargo workspace.
Release Notes:
- N/A
This PR improves the initial experience of using `/docs docs-rs` with an
empty index.
We now show a brief explainer of what is expected (a crate name) as well
as list some popular Rust crates to try:
<img width="540" alt="Screenshot 2024-08-13 at 12 25 39 PM"
src="https://github.com/user-attachments/assets/942de250-2901-45df-9e3e-52ff3b3fc517">
Release Notes:
- N/A
This PR updates the `/docs` slash command with the ability to
just-in-time index a package when there are not yet any results in the
index.
When running a `/docs` slash command, we fist check to see if there are
any results in the index that would match the search.
If there are, we go ahead and return them, as we do today.
However, if there are not yet any results we kick off an indexing task
as part of the command execution to fetch the results.
Release Notes:
- N/A
This PR updates the `/docs` slash command with basic globbing support
for expanding docs.
A `*` can be added to the item path to signify the end of a prefix
match.
For example:
```
# This will match any documentation items starting with `auk::`.
# In this case, it will pull in the docs for each item in the crate.
/docs docs-rs auk::*
# This will match any documentation items starting with `auk::visitor::`,
# which will pull in docs for the `visitor` module.
/docs docs-rs auk::visitor::*
```
https://github.com/user-attachments/assets/5e1e21f1-241b-483f-9cd1-facc3aa76365
Release Notes:
- N/A
This PR improves the error message shown by the `/docs` slash command
when indexing fails due to the absence of `target/doc`.
We now distinguish between the overall `target/doc` directory missing
and an individual crate directory missing beneath it.
Release Notes:
- N/A
This PR updates the `/docs` slash command to show a warning to the user
if a crate's docs cannot be indexed due to the target directory not
containing docs:
<img width="782" alt="Screenshot 2024-07-11 at 5 11 46 PM"
src="https://github.com/user-attachments/assets/2f54f7a1-97f4-4d2d-b51f-57ba31e50a2f">
Release Notes:
- N/A
This PR adds a new `/docs` slash command to the Assistant. This slash
command replaces `/rustdoc`.
The `/docs` slash command works with different providers. There is
currently a built-in provider for rustdoc, but new providers can be
defined within extensions. The Gleam extension contains an example of
this.
When you first type `/docs` a completion menu will be shown with the
list of available providers:
https://github.com/zed-industries/zed/assets/1486634/32287000-5855-44d9-a2eb-569596f5abd9
After completing the provider you want to use then you can type the
package name and/or item path to search for the relevant docs:
https://github.com/zed-industries/zed/assets/1486634/6fc55a63-7fcd-42ea-80ce-08c670bf03fc
There are still some rough edges around completions that I would like to
get cleaned up in a future PR. Both of these seem to stem from the fact
that we're using an intermediate completion in the slash command:
1. Accepting a provider completion will show an error until you press
<kbd>Space</kbd> to continue typing.
- We need a way of not submitting a slash command when a completion is
accepted.
2. We currently need to show the provider name in the documentation item
completion list.
- Without it, the provider name gets wiped out when accepting a
completion, causing the slash command to become invalid.
Release Notes:
- N/A
This PR begins the process of making the backing infrastructure for the
`/rustdoc` command more generic such that it can be applied to
additional documentation providers.
In this PR we:
- Rename the `rustdoc` crate to `indexed_docs` as a more general-purpose
name
- Start moving rustdoc-specific functionality into
`indexed_docs::providers::rustdoc`
- Add an `IndexedDocsRegistry` to hold multiple `IndexedDocsStore`s (one
per provider)
We haven't yet removed the rustdoc-specific bits in the `DocsIndexer`.
That will follow soon.
Release Notes:
- N/A
