Zed is becoming more popular and our issue tracker is only growing
larger and larger. I realize that a stale issue action can be
controversial, but the way we currently manage issues hasn't scaled well
and it will only get worse. We need some crowd-sourced system. Let's ask
those who have opened issues if their issues are still valid. This is
rather conservative and only targets bugs and crashes. I'll run it in
debug mode, report the results, and enable it if it feels right. We can
always turn this off if users end up really not liking it.
My original rules were:
```txt
If an issue is old enough (12 months or older)
AND if there are no recent comments from the team (last dev comment is older than 6 months)
AND it has less than X upvotes (5)
AND it does not have an open PR linked to it
AND is a "defect" or "panic / crash"
AND does not have a "ignore top-ranking issues" label
AND was not opened by a org member
AND is open
AND is issue (not a pull request)
THEN close the issue with a kind message.
```
But only some of these were actually supported in the configuration.
Release Notes:
- N/A
In #17974 we explicitly depend on rustc/cargo for the nix devShell,
however the fenix overlay that contains the latest stable versions was
not being applied to that shell. This led to the shell inheriting
whatever rustc/cargo was on nixos-unstable from nixpkgs, which sometimes
lags behind. This change fixes that, and also restructures the flake to
ensure that all outputs rely on the overlaid `pkgs`.
Release Notes:
- N/A
Related to https://github.com/rust-lang/rust-analyzer/pull/18167
* Declare more completion item fields in the client completion resolve
capabilities
* Do resolve completions even if their docs are present
* Instead, do not resolve completions that could not be resolved when
handling the remote client resolve requests
* Do replace the old lsp completion data with the resolved one
Release Notes:
- Improved completion resolve mechanism
1. Raised the `Indent Guides` heading to level 2, which is completely
unrelated to `Git`.
2. the `Git` heading now only contains `Git Gutter` and `Inline Git
Blame` as subheadings.
3. The `Indent Guides` heading is now located directly after the `Git`
heading.
Release Notes:
- N/A
Fixed a bug where the `always_treat_brackets_as_autoclosed` option would
not display the message in the tooltip that appears when hovering.
Release Notes:
- N/A
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 PR introduces functionality for creating *branches* of buffers that
can be used to preview and edit change sets that haven't yet been
applied to the buffers themselves.
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Marshall <marshall@zed.dev>
* [x] put this slash command behind a feature flag until we release
embedding access to the general population
* [x] choose a name for this slash command and name the rust module to
match
Release Notes:
- N/A
---------
Co-authored-by: Jason <jason@zed.dev>
Co-authored-by: Richard <richard@zed.dev>
Co-authored-by: Jason Mancuso <7891333+jvmncs@users.noreply.github.com>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Release Notes:
- Allow Anthropic custom models to override "temperature"
This also centralized the defaulting of "temperature" to be inside of
each model's `into_x` call instead of being sprinkled around the code.
This PR removes some unneeded blank lines from some of the test cases
for `editor::Rewrap`.
These weren't meaningful to the test, and their presence could be
confusing.
Release Notes:
- N/A
This PR improves the `editor::Rewrap` command when working with comments
that were not all at the same indentation level.
We now use a heuristic of finding the most common indentation level for
each line, using the deepest indent in the event of a tie.
It also removes an `.unwrap()` that would previously lead to a panic in
this case. Instead of unwrapping we now log an error to the logs and
skip rewrapping for that selection.
Release Notes:
- Improved the behavior of `editor: rewrap` when working with a
selection that contained comments at different indentation levels.
This PR removes the `replica_id` field from the `MultiBuffer` struct.
We were only ever referencing this field to pass when constructing a
`MultiBuffer`, and never used it outside of that.
Release Notes:
- N/A
Now when an individual project eval fails, instead of panicking we add
it to a list of failures that we collect and report at the end (and make
the exit code nonzero).
Release Notes:
- N/A
This PR makes it so after a scheduled Nightly build we also update the
`nightly` tag to keep things in sync.
It's safe to bump the tag within this Action, as it won't trigger
another Nightly build due to GitHub's recursive Action protections:
> When you use the repository's `GITHUB_TOKEN` to perform tasks, events
triggered by the `GITHUB_TOKEN`, with the exception of
`workflow_dispatch` and `repository_dispatch`, will not create a new
workflow run. This prevents you from accidentally creating recursive
workflow runs. For example, if a workflow run pushes code using the
repository's `GITHUB_TOKEN`, a new workflow will not run even when the
repository contains a workflow configured to run when `push` events
occur.
>
> —
[source](https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow)
Release Notes:
- N/A
This fixes the bug with hover tooltips appearing multiple times.
Turns out everytime we receive the `CreateLanguageServer` message we'd
add a new adapter but only have a single server running for all of them.
And we send a `CreateLanguageServer` message everytime you open a
buffer.
What this does is to only add a new adapter if it hasn't already been
registered, which is also what we do locally.
Release Notes:
- N/A
This PR reverts #17879, as it wasn't working.
When a GitHub Action pushes a tag, it does not trigger workflows for
push events for that tag:
> When you use the repository's `GITHUB_TOKEN` to perform tasks, events
triggered by the `GITHUB_TOKEN`, with the exception of
`workflow_dispatch` and `repository_dispatch`, will not create a new
workflow run. This prevents you from accidentally creating recursive
workflow runs. For example, if a workflow run pushes code using the
repository's `GITHUB_TOKEN`, a new workflow will not run even when the
repository contains a workflow configured to run when `push` events
occur.
>
> —
[source](https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow)
This reverts commit 761129e373.
Release Notes:
- N/A
Closes#16876
We only ever showed parsing errors, but not if something failed to
deserialize.
Basically, if you had a stray `,` somewhere, we'd show a notification
for user errors, but only squiggly lines if you had a `[]` instead of a
`{}`.
The squiggly lines would only show up when there were schema errors.
In the case of `formatter` settings, for example, if someone put in a
`{}` instead of `[]`, we'd never show anything.
With this change we always show a notification if parsing user or
project settings fails.
(Right now, the error message might still be bad, but that's a separate
change)
Release Notes:
- Added a notification to warn users if their user settings or
project-local settings failed to deserialize.
Demo:
https://github.com/user-attachments/assets/e5c48165-f2f7-4b5c-9c6d-6ea74f678683
Release Notes:
- Added a new `assistant.inline_alternatives` setting to configure
additional models that will be used to perform inline assists in
parallel.
---------
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Roy <roy@anthropic.com>
Co-authored-by: Adam <wolffiex@anthropic.com>
