Implements a specialized constructor `LanguageName::new_static` for
`&'static str` which reduces allocations.
`LanguageName::new` always backs the underlying `SharedString` with an
owned `Arc<str>` even when a `&'static str` is passed. This makes us
allocate each time we create a new `LanguageName` no matter what.
Creating a specialized constructor for `&'static str` allows us to
essentially construct them for free.
Additional change:
Encourages using explicit constructors to avoid needless allocations.
Currently there were no instances of this trait being called where the
lifetime was not `'static` saving another 48 locations of allocation.
```rust
impl<'a> From<&'a str> for LanguageName {
fn from(str: &'a str) -> Self {
Self(SharedString::new(str))
}
}
// to
impl From<&'static str> for LanguageName {
fn from(str: &'static str) -> Self {
Self(SharedString::new_static(str))
}
}
```
Release Notes:
- N/A
Release Notes:
- Fixed the behavior of the attach to process feature for the Golang
debugger.
**Step to reprorduce:**
1. Build and run golang binary
2. In Zed open debugger
3. Go to Attach tab
4. Select the binary you just built from the list
**Actual result:**
```
Tried to launch debugger with: {
"request": "attach",
"mode": "debug",
"processId": 74702,
"stopOnEntry": false,
"cwd": "/path/to/the/current/working/directory"
}
error: Failed to attach: invalid debug configuration - unsupported 'mode' attribute "debug"
```
**Expected result:** The debugger can attach to the process.
According to the [Delve
documentation](https://github.com/go-delve/delve/tree/master/Documentation/api/dap#launch-and-attach-configurations)
`attach` request supports `local` and `remote` values only
Closes#42727
Unfortunately we can only support IPv4 addresses right now because
`TcpArguments` only supports an IPv4 address. I'm not sure how difficult
it would be to lift this limitation.
Release Notes:
- Fixed `connect.host` setting being ignored by debugpy
Co-authored-by: Cole Miller <cole@zed.dev>
I really need this for embedded development in IDF and Zephyr, where the
chip vendors sometimes provide there own specialized version of the
tools, and I need to direct zed to use these.
The current GDB adapter only supports the gdb it find in the normal
search path, and it also seems like we where not able to transfer gdb
specific startup arguments (only `-i=dap` is set) .
In order to fix this I (semi wipe using GPT-4.1) expanded the GDB
adapter with 2 new config options :
* **gdb_path** holds a full path to the gdb executable, for now only
full path or relative to cwd
* **gdb_args** an array holding additional arguments given to gdb on
startup
It seemed to me, like the `env` config did not transferred to gdb, so
this is added to.
I have tested this locally, and it seems to work not only compile :-)
Release Notes:
debugger: Adds gdb_path and gdb_args to gdb debug adapter options
debugger: Fix bug where gdb debug sessions wouldn't inherit the shell
environment from Zed
---------
Co-authored-by: Anthony <anthony@zed.dev>
Fixes the Debugpy toolchain detection bug in #40324
When detecting what toolchain (venv) to use in the Debugpy configuration
stage, we used to only base it off of the current working directory
argument passed to the config. This is wrong behavior for cases like
mono repos, where the correct virtual environment to use is nested in
another folder.
This PR fixes this issue by adding the program and module fields as
fallbacks to check for virtual environments. We also added support for
program/module relative paths as well when cwd is not None.
Release Notes:
- debugger: Improve mono repo virtual environment detection with Debugpy
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Closes#38345, #34882, #33280
Debugpy has four distinct configuration scenarios, which are:
1. launch
2. attach with process id
3. attach with listen
4. attach with connect
Spawning Debugpy directly works with the first three scenarios but not
with "attach with connect". Which requires host/port arguments being
passed in both with an attach request and when starting up Debugpy. This
PR passes in the right arguments when spawning Debugpy in an attach with
connect scenario, thus fixing the bug.
The VsCode extension comment that explains this:
98f5b93ee4/src/extension/debugger/adapter/factory.ts (L43-L51)
Release Notes:
- debugger: Fix Python attach-based sessions not working with `connect`
or `port` arguments
Using `shlex` unconditionally is dangerous as it assumes the underlying
shell is POSIX which is not the case for PowerShell, CMD, or Nushell.
Therefore, whenever we want to quote the args we should utilise our
helper `util::shell::ShellKind::try_quote` which takes into account
which shell is being used to actually exec/spawn the invocation.
Release Notes:
- N/A
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
We've been considering removing workspace-hack for a couple reasons:
- Lukas ran into a situation where its build script seemed to be causing
spurious rebuilds. This seems more likely to be a cargo bug than an
issue with workspace-hack itself (given that it has an empty build
script), but we don't necessarily want to take the time to hunt that
down right now.
- Marshall mentioned hakari interacts poorly with automated crate
updates (in our case provided by rennovate) because you'd need to have
`cargo hakari generate && cargo hakari manage-deps` after their changes
and we prefer to not have actions that make commits.
Currently removing workspace-hack causes our workspace to grow from
~1700 to ~2000 crates being built (depending on platform), which is
mainly a problem when you're building the whole workspace or running
tests across the the normal and remote binaries (which is where
feature-unification nets us the most sharing). It doesn't impact
incremental times noticeably when you're just iterating on `-p zed`, and
we'll hopefully get these savings back in the future when
rust-lang/cargo#14774 (which re-implements the functionality of hakari)
is finished.
Release Notes:
- N/A
It is now possible to configure logging level of CodeLLDB adapter via
envs specified in project settings like so:
```
{
"dap": {
"CodeLLDB": {
"envs": {
"RUST_LOG": "debug"
}
}
}
}
```
Release Notes:
- N/A
Fixes#39998
Debugpy and pylsp are installed in a Zed-global venv with pip. We need a
Python interpreter to create this venv when it doesn't exist and one of
these tools needs to be installed, and sometimes we attempt to use
`python3` from `$PATH`. This can cause issues on Windows, where out of
the box `python3` is a sort of shim that opens the Microsoft Store app.
This PR changes the debugpy installation path to create the Zed-global
venv using the Python interpreter from a venv in the project, and only
use python3 from `$PATH` if that fails. That matches how pylsp
installation already works. It also tightens up how we search for a
global Python installation by doing a basic sanity check (`python3 -c
'print(1 + 2)`) before accepting it, which should catch the Windows
shim.
Release Notes:
- windows: improved the behavior of Zed in situations where no global
Python installation exists.
This PR adds support for browser debugging in SSH and WSL projects. We
use the vscode-js-debug-companion extension, repackaged as a standalone
CLI (https://github.com/zed-industries/js-debug-companion-cli).
Closes#38878
Release Notes:
- debugger: Browser debugging is now supported in SSH and WSL projects.
---------
Co-authored-by: Nia <nia@zed.dev>
Closes https://github.com/zed-industries/zed/issues/38690Closes#37353
### Background
On Windows, paths are normally separated by `\`, unlike mac and linux
where they are separated by `/`. When editing code in a project that
uses a different path style than your local system (e.g. remoting from
Windows to Linux, using WSL, and collaboration between windows and unix
users), the correct separator for a path may differ from the "native"
separator.
Previously, to work around this, Zed converted paths' separators in
numerous places. This was applied to both absolute and relative paths,
leading to incorrect conversions in some cases.
### Solution
Many code paths in Zed use paths that are *relative* to either a
worktree root or a git repository. This PR introduces a dedicated type
for these paths called `RelPath`, which stores the path in the same way
regardless of host platform, and offers `Path`-like manipulation APIs.
RelPath supports *displaying* the path using either separator, so that
we can display paths in a style that is determined at runtime based on
the current project.
The representation of absolute paths is left untouched, for now.
Absolute paths are different from relative paths because (except in
contexts where we know that the path refers to the local filesystem)
they should generally be treated as opaque strings. Currently we use a
mix of types for these paths (std::path::Path, String, SanitizedPath).
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Peter Tripp <petertripp@gmail.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
This PR adds a toggleable filter to the stack frame list that filters
out entries that don't exist within a user's project (visible work
trees). This works by keeping a vector of entry indices that exist
within a user's project and updates the list state based on these
entries when filtering the list.
I went with this approach so the stack frame list wouldn't have to
rebuild itself whenever the filter is toggled and it could persist its
state across toggles (uncollapsing a collapse list). It was also easier
to keep track of selected entries on toggle using the vector as well.
### Preview
https://github.com/user-attachments/assets/d86c7485-c885-4bbb-bebb-2f6385674925
Release Notes:
- debugger: Add option to only show stack frames from user's project in
stack frame list
Another stab at #35388
cc @Sansui233
Closes#35388
Release Notes:
- debugger: Fixed Python debug sessions failing to launch due to a
missing debugpy installation.
Closes#35388
Release Notes:
- debugger: Fixed Python debug sessions failing to launch due to a
missing debugpy installation. Debugpy is now installed into user's venv
if there's one available.
@cole-miller found a root cause of our struggles with attach scenarios;
we did not fetch .so files necessary for attaching to work,
as we were downloading DebugPy source tarballs from GitHub.
This PR does away with it by setting up a virtualenv instead that has
debugpy installed.
Closes#34660Closes#34575
Release Notes:
- debugger: Fixed attaching with DebugPy. DebugPy is now installed
automatically from pip (instead of GitHub), unless it is present in
active virtual environment. Additionally this should resolve any startup
issues with missing .so on Linux.
Previously we would append `js-debug/src/dapDebugServer.js` to the value
of the `dap.JavaScript.binary` setting and `src/debugpy/adapter` to the
value of the `dap.Debugpy.binary` setting, which isn't particularly
intuitive. This PR fixes that.
Release Notes:
- debugger: Made the semantics of the `dap.$ADAPTER.binary` setting more
intuitive for the `JavaScript` and `Debugpy` adapters. In the new
semantics, this should be the path to `dapDebugServer.js` for
`JavaScript` and the path to the `src/debugpy/adapter` directory for
`Debugpy`.
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
This PR updates the debugger panel's session list to be more useful in
some cases that are commonly hit when using the JavaScript adapter. We
make two adjustments, which only apply to JavaScript sessions:
- For a child session that's the only child of a root session, we
collapse it with its parent. This imitates what VS Code does in the
"call stack" view for JavaScript sessions.
- When a session has exactly one thread, we label the session with that
thread's name, instead of the session label provided by the DAP. VS Code
also makes this adjustment, which surfaces more useful information when
working with browser sessions.
Closes#33072
Release Notes:
- debugger: Improved the appearance of JavaScript sessions in the debug
panel's session list.
---------
Co-authored-by: Julia <julia@zed.dev>
Co-authored-by: Remco Smits <djsmits12@gmail.com>
This commit removes the PHP debug adapter in favor of a new version
(0.3.0) of PHP extension.
The name of a debug adapter has been changed from "PHP" to "Xdebug",
which makes this a breaking change in user-configured scenarios
Release Notes:
- debugger: PHP debug adapter is no longer shipped in core Zed editor;
it is now available in PHP extension (starting with version 0.3.0). The
adapter has been renamed from `PHP` to `Xdebug`, which might break your
user-defined debug scenarios.
There were a couple of things preventing this from working:
- our hack to stop the node REPL from appearing broke in recent versions
of the JS DAP that started passing `--experimental-network-inspection`
by default
- we had lost the ability to create a debug terminal without specifying
a program
This PR fixes those issues. We also fixed environment variables from the
**runInTerminal** request not getting passed to the spawned program.
Release Notes:
- Debugger: Fix RunInTerminal not working for JavaScript debugger.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
`program` isn't required, and in fact our built-in `JavaScript debug
terminal` configuration doesn't have it.
Also add `node-terminal` to the list of allowed types.
Co-authored-by: Michael <michael@zed.dev>
Release Notes:
- N/A
Just like vscode-js-debug, debugpy uses the `name` key in
StartDebuggingRequestArguments for this:
0d65353cc6/src/debugpy/adapter/clients.py (L753)
Release Notes:
- debugger: Made the names of Python subprocesses in the session list
more helpful.
Related to #33072
We use the JS adapter's suggested names for child sessions, but
sometimes it sends us `""`, so don't use that one.
Release Notes:
- debugger: Fixed nameless child sessions appearing with the JavaScript
adapter.
- **debugger: Update exception breakpoints list on capability update**
- **Do not prefill codelldb sourcelanguages by default**
Release Notes:
- debugger: CodeLLDB no longer enables pretty-printers for Rust by
default. This fixes pretty-printers for C++. This is a breaking change
for user-defined debug scenarios from debug.json; in order to enable
Rust pretty printing when using CodeLLDB, add `"sourceLanguages":
["rust"]` to your debug configuration. This change does not affect
scenarios automatically inferred by Zed.
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
Now that the extension version has been bumped we can remove our in-tree
one to avoid having duplicate debug adapters.
Release Notes:
- The ruby debug adapter has been moved to the [ruby
extension](https://github.com/zed-extensions/ruby), if you have any
saved debug scenarios you'll need to change `"adapter": "Ruby"` to
`"adapter": "rdbg"`.
- Normalize `node-terminal` to `pwa-node` before sending to DAP
- Split `command` into `program` and `args`
- Run in external console
Release Notes:
- debugger: Fixed debugging JavaScript tasks that used `"type":
"node-terminal"`.
## Context
To support inline values a language will have to implement their own
provider trait that walks through tree sitter nodes. This is overly
complicated, hard to accurately implement for each language, and lacks
proper extension support.
This PR switches to a singular inline provider that uses a language's
`debugger.scm` query field to capture variables and scopes. The inline
provider is able to use this information to generate inlays that take
scope into account and work with any language that defines a debugger
query file.
### Todos
- [x] Implement a utility test function to easily test inline values
- [x] Generate inline values based on captures
- [x] Reimplement Python, Rust, and Go support
- [x] Take scope into account when iterating through variable captures
- [x] Add tests for Go inline values
- [x] Remove old inline provider code and trait implementations
Release Notes:
- debugger: Generate inline values based on a language debugger.scm file
Custom arguments replace any arguments that we normally pass to the DAP.
For interpreted languages, they are passed to the interpreter after the
DAP path or module. They can be combined with a custom binary, or you
can omit `dap.binary` and just customize the arguments to the DAPs we
download.
This doesn't take care of updating the extension API to support custom
arguments.
Release Notes:
- debugger: Implemented support for passing custom arguments to a debug
adapter binary using the `dap.args` setting.
- debugger: Fixed not being able to use the `dap` setting in
`.zed/settings.json`.
We were translating port configuration incorrectly, using it for both
attach target and debugger port.
This however meant that we were spawning a 2nd process that'd listen on
the same port as the existing debugger.
Closes#32836
Release Notes:
- debugger: Fixed issues with auto-translated Visual Studio Code debug
configs for attaching to existing node debugger instances.
