This PR adds passing in `stop_on_entry` to debug configs in debug.json
instead of going through initialization args.
This has two benefits:
1. It's more streamlined to a user since every internal adapter supports
`stop_on_entry` for launch requests and Go's adapter supports it for
attach requests too.
2. It will allow @osiewicz `NewSesssionModal` PR to use this field for
the stop on entry checkbox.
Release Notes:
- N/A
## Summary
This PR starts the process of adding debug task locators to Zed's
debugger system. A task locator is a secondary resolution phase that
allows a debug task to run a command before starting a debug session and
then uses the output of the run command to configure itself.
Locators are most applicable when debugging a compiled language but will
be helpful for any language as well.
## Architecture
At a high level, this works by adding a debug task queue to `Workspace`.
Which add's a debug configuration associated with a `TaskId` whenever a
resolved task with a debug config is added to `TaskInventory`'s queue.
Then, when the `SpawnInTerminal` task finishes running, it emits its
task_id and the result of the ran task.
When a ran task exits successfully, `Workspace` tells `Project` to start
a debug session using its stored debug config, then `DapStore` queries
the `LocatorStore` to configure the debug configuration if it has a
valid locator argument.
Release Notes:
- N/A
This pull request paves way for exposing manifest tracking to
extensions.
- Project tree was renamed to manifest tree to better reflect it's
intent (and avoid confusion).
- Language server adapters now provide a name of their *manifest
locator*. If multiple language servers refer to the same locator, the
locating code will run just once for a given path.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Anthony <anthony@zed.dev>
Similar to how tasks are fetched via LSP, also queries for document's
code lens and filters the ones with the commands, supported in server
capabilities.
Whatever's left and applicable to the range given, is added to the
actions menu:
This way, Zed can get more actions to run, albeit neither r-a nor vtsls
seem to provide anything by default.
Currently, there are no plans to render code lens the way as in VSCode,
it's just the extra actions that are show in the menu.
------------------
As part of the attempts to use rust-analyzer LSP data about the
runnables, I've explored a way to get this data via standard LSP.
When particular experimental client capabilities are enabled (similar to
how clangd does this now), r-a starts to send back code lens with the
data needed to run a cargo command:
```
{"jsonrpc":"2.0","id":48,"result":{"range":{"start":{"line":0,"character":0},"end":{"line":98,"character":0}},"command":{"title":"▶︎ Run Tests","command":"rust-analyzer.runSingle","arguments":[{"label":"test-mod tests::ecparser","location":{"targetUri":"file:///Users/someonetoignore/work/ec4rs/src/tests/ecparser.rs","targetRange":{"start":{"line":0,"character":0},"end":{"line":98,"character":0}},"targetSelectionRange":{"start":{"line":0,"character":0},"end":{"line":98,"character":0}}},"kind":"cargo","args":{"environment":{"RUSTC_TOOLCHAIN":"/Users/someonetoignore/.rustup/toolchains/1.85-aarch64-apple-darwin"},"cwd":"/Users/someonetoignore/work/ec4rs","overrideCargo":null,"workspaceRoot":"/Users/someonetoignore/work/ec4rs","cargoArgs":["test","--package","ec4rs","--lib"],"executableArgs":["tests::ecparser","--show-output"]}}]}}}
```
This data is passed as is to VSCode task processor, registered in
60cd01864a/editors/code/src/main.ts (L195)
where it gets eventually executed as a VSCode's task, all handled by the
r-a's extension code.
rust-analyzer does not declare server capabilities for such tasks, and
has no `workspace/executeCommand` handle, and Zed needs an interactive
terminal output during the test runs, so we cannot ask rust-analyzer
more than these descriptions.
Given that Zed needs experimental capabilities set to get these lens:
60cd01864a/editors/code/src/client.ts (L318-L327)
and that the lens may contain other odd tasks (e.g. docs opening or
references lookup), a protocol extension to get runnables looks more
preferred than lens:
https://rust-analyzer.github.io/book/contributing/lsp-extensions.html#runnables
This PR does not include any work on this direction, limiting to the
general code lens support.
As a proof of concept, it's possible to get the lens and even attempt to
run it, to no avail:
Release Notes:
- Used `textDocument/codeLens` data in the actions menu when applicable
This PR is an attempt to add support for `--target-dir` argument to
`cargo` commands when executing tasks with rust.
When using VSCode I was already using this trick to not block the
current binary compilation when I was trying a specific test. As it's a
different target directory it won't block the `cargo` commands I'm using
in my terminal.
I used the task variables to achieve this but I'm not sure it's the best
option to be honest. I didn't find any examples in your docs to see if
sometimes you had specific configuration for languages and tasks.
Let me know if this solution would be a good fit and if the
implementation is ok.
If so feel free to redirect me to an example I can reproduce to write a
unit test or so... And I will also update the docs.
Example of config:
```
{
"languages": {
"Rust": {
"tasks": {
"variables": {
"RUST_TARGET_DIR": ".cargo_check"
}
}
}
}
}
```
it will run `cargo test -p XXX --target-dir .cargo-check`
Release Notes:
- Added support for `--target-dir` for Rust tasks
---------
Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>
Screenshot:
I would be happy to add tests if you point me to the right place to do
it please.
Release Notes:
- Added support for doc test in tasks for Rust
---------
Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>
Fix a bug where a GPUI macro still used `ModelContext`
Rename `AsyncAppContext` -> `AsyncApp`
Rename update_model, read_model, insert_model, and reserve_model to
update_entity, read_entity, insert_entity, and reserve_entity
Release Notes:
- N/A
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>
Also changed rust tasks to be less mouthful.
Release Notes:
- Shortened Rust task labels.
- Task modal will now use full task label when it does not require
truncation.
This PR introduces a new entity called Project Tree which is responsible
for finding subprojects within a worktree;
a subproject is a language-specific subset of a worktree which should be
accurately tracked on the language server side. We'll have an ability to
set multiple disjoint workspaceFolders on language server side OR spawn
multiple instances of a single language server (which will be the case
with e.g. Python language servers, as they need to interact with
multiple disjoint virtual environments).
Project Tree assumes that projects of the same LspAdapter kind cannot
overlap. Additionally project nesting is not allowed within the scope of
a single LspAdapter.
Closes https://github.com/zed-industries/zed/issues/5108
Re-lands #22182 which I had to revert due to merging it into todays
Preview.
Release Notes:
- Language servers now track their working directory more accurately.
---------
Co-authored-by: João <joao@zed.dev>
This PR introduces a new entity called Project Tree which is responsible
for finding subprojects within a worktree;
a subproject is a language-specific subset of a worktree which should be
accurately tracked on the language server side. We'll have an ability to
set multiple disjoint `workspaceFolder`s on language server side OR
spawn multiple instances of a single language server (which will be the
case with e.g. Python language servers, as they need to interact with
multiple disjoint virtual environments).
Project Tree assumes that projects of the same LspAdapter kind cannot
overlap. Additionally **project nesting** is not allowed within the
scope of a single LspAdapter.
Closes#5108
Release Notes:
- Language servers now track their working directory more accurately.
---------
Co-authored-by: João <joao@zed.dev>
Closes https://github.com/zed-industries/zed/issues/22642
In Zed, Rust's label generators expected the details to come in ` (use
std.foo.Bar)` form, but recently, r-a started to send these details
without the leading whitespace which broke the code generation.
The PR makes LSP results parsing more lenient to work with both details'
forms.
Release Notes:
- Fixed Rust completion labels not showing the imports
After https://github.com/rust-lang/rust-analyzer/pull/18412, there is no
longer a .gz file for windows rust-analyzer targets, and the rust
analyzer LSP fails to download. This fixes it by using the .zip version
on windows.
The .zip also extracts to a _folder_ containing rust-analyzer.exe rather
than just a file. I've handled it in this code, but am not 100% sure if
other parts of the code need too be aware of it.
Release Notes:
- N/A
This fixes the issue of multiple language servers showing up as `node`
in the language server logs dropdown.
It does this by changing `language_server.name()` to return the
adapter's name, not the binary name, and changing types to make sure
that we always use this.
Release Notes:
- Fixed language server names showing up only as `"node"`
---------
Co-authored-by: Sam Rose <hello@samwho.dev>
Co-authored-by: Bennet <bennet@zed.dev>
Closes https://github.com/zed-industries/zed/issues/8534
Supersedes https://github.com/zed-industries/zed/pull/16349
Potential concerns:
* we do not follow up to the `/` when looking for `.editorconfig`, only
up to the worktree root.
Seems fine for most of the cases, and the rest should be solved
generically later, as the same issue exists for settings.json
* `fn language` in `AllLanguageSettings` is very hot, called very
frequently during rendering. We accumulate and parse all `.editorconfig`
file contents beforehand, but have to go over globs and match these
against the path given + merge the properties still.
This does not seem to be very bad, but needs more testing and
potentially some extra caching.
Release Notes:
- Added .editorconfig support
---------
Co-authored-by: Ulysse Buonomo <buonomo.ulysse@gmail.com>
Release Notes:
- Fixed overriding the path of a language server binary for all language
servers. `{"lsp":{"<lsp-name>":{"binary":{"path": "_"}}}}` will now work
for all language servers including those defined by extensions.
- (breaking change) To disable finding lsp adapters in your path, you
must now specify
`{"lsp":{"<lsp-name>":{"binary":{"ignore_system_version": true}}}}`.
Previously this was `{"lsp":{"<lsp-name>":{"binary":{"path_lookup":
false}}}}`. Note that this setting still does not apply to extensions.
- Removed automatic reinstallation of language servers. (It mostly
didn't work)
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
This pushes the new LanguageServerName type to more places.
As both languages and language servers were identified by Arc<str>, it
was
sometimes hard to tell which was intended.
Release Notes:
- N/A
This is a follow-up to https://github.com/zed-industries/zed/pull/17885,
which is reverted and fixed in this PR.
This PR actually enables the behavior by default.
Release Notes:
- Changed `rust-analyzer` support to lookup `rust-analyzer` binaries by
default in `$PATH`. That changes the default value to something users
requested.
Fixes https://github.com/zed-industries/zed/issues/5291
Release Notes:
- Fixed a bug where the 'toggle comments' command didn't use the right
comment syntax in JSX and TSX elements.
---------
Co-authored-by: Conrad <conrad@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
This is a highly and frequently requested change. Users are confused why
rust-analyzer isn't used if it's on their `$PATH`.
Previously I didn't enable this by default, because rust-analyzer would
complain about an "Unknown binary", like this
Unknown binary 'rust-analyzer' in official toolchain
'1.81-aarch64-apple-darwin'.\n
But turns out that only happens when you have installed rust-analyzer
via the rustup toolchain, it's in your `$PATH`, and the
`rust-toolchain.toml` of the repository doesn't mention it.
The fix is to delete `~/.cargo/bin/rust-analyzer` and, if preferred, use
`rust-analyzer` by installing the binary manually.
Release Notes:
- Changed rust-analyzer support to lookup `rust-analyzer` binaries by
default in `$PATH`. That changes the default value to something users
requested.
Release Notes:
- Changed built-in language support (Rust, Go, C, YAML, ...) to lookup
language-server specific settings locally in project directory first
before falling back to global value.
---------
Co-authored-by: Bennet <bennet@zed.dev>
What do all of the syntax-highlighted methods have in common in this
screenshot?
<img width="597" alt="image"
src="https://github.com/user-attachments/assets/7e3cced5-1857-44ca-8000-d2aa3c485726">
They're all trait methods. This is an unfortunate byproduct of how we
parse function signatures and handle details of completions. Other
non-syntax highlighted entries could get the highlighting for free, if
not for the fact that they lack a bit of data that is available for
trait methods.
This PR fixes this problem.
<img width="597" alt="image"
src="https://github.com/user-attachments/assets/065dc929-be00-46fc-a7c3-e63ed7ad6a0a">
Release Notes:
- Improved syntax highlighting of Rust methods in completions menu
Closes#15860
Since rust std now supports LazyLock replacing lazy_static with it
reduce the external dependency.
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
