Dom PoradaandMrSubidubi 9dbc9e76c1 Stop prompting to migrate settings that contain no deprecations (#62818)
## Objective

Zed can report that a settings file uses deprecated settings even when
it contains no deprecations. A context server configured with only a
`url` is enough to trigger the prompt, although the backup Zed offers to
write is identical to the current file.

Fixes #24967.

## Solution

Two text-edit migrations cancel each other on `context_servers` entries:
one adds a `source` key and a later one removes it. The round trip
reindents the entry, and the migrator mistakes the leftover whitespace
for a migration.

Remove `m_2025_06_16` rather than comparing around that whitespace. It
wrote `source` and `settings` into every entry, but
`ContextServerSettingsContent` contains neither field today. `settings`
is worse than inert: an empty entry such as `{ "settings": {} }` matches
neither the `Stdio` nor `Http` variant of the untagged enum.

Update `m_2025_06_27`, the only remaining consumer of the generated
`"source": "custom"`, to detect legacy entries from the shape of
`command` itself. This continues to flatten settings written before
`source` existed. It also deliberately flattens an object `command`
beside `"source": "extension"`, which the old migration skipped. The
command shape is invalid regardless of the declared source, and a test
pins the new behavior. `m_2025_11_25` remains unchanged because it still
removes `source` from settings that genuinely carry it.

This deletes one migration and edits another despite the warning at the
top of `migrator.rs`. That warning protects later migrations that depend
on earlier output, but this output has no remaining consumer. I left the
policy unchanged rather than adding an exception in the same PR that
relies on it, but I can document the exception if preferred.

## Testing

- `cargo test -p migrator` passes, 86 tests. The suite loses the three
tests that only exercised the deleted migration and gains
`test_flatten_context_server_command_alongside_source`, covering a
legacy entry that carries both `source` and an object `command`.
- Restoring the `source` requirement on `m_2025_06_27` with the deletion
in place turns `test_flatten_context_server_command` red. Its input is a
pre-`source` entry, which is what makes the relaxation load-bearing
rather than incidental.
- To check by hand: add `"context_servers": { "grep": { "url":
"https://mcp.grep.app" } }` to user settings and confirm no migration
prompt appears. Add `"show_inline_completions": true` alongside it and
confirm the prompt returns and leaves the context server block
untouched.
- I have not run those steps in a built editor. The tests call
`migrate_settings`, which is all `should_migrate_settings` checks before
raising the prompt, so that call is the whole untested gap. It’s all
platform-independent text processing, so I did not test Linux or
Windows.

## Self-Review Checklist:

- [x] I’ve reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed’s UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

---

Release Notes:

- Fixed the migration prompt appearing for settings that contain no
deprecations. Context servers configured with only a `url` no longer
trigger it.

---------

Co-authored-by: MrSubidubi <finn@zed.dev>
2026-08-29 22:33:35 +00:00
2026-08-12 08:35:43 +00:00
2026-01-22 23:57:26 +05:30
2026-08-28 20:04:24 +00:00
2026-08-28 17:22:25 +00:00
WIP
2023-12-14 09:25:14 -07:00
2026-08-09 22:29:52 +00:00
2026-08-09 22:29:52 +00:00
2025-02-04 09:02:59 -05:00
2025-10-27 13:27:59 -04:00
2025-10-17 18:58:14 +00:00
2026-03-17 16:34:35 +00:00

Zed

Zed CI

Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.


Installation

On macOS, Linux, and Windows you can download Zed directly or install Zed via your local package manager (macOS/Linux/Windows).

Other platforms are not yet available:

Developing Zed

Contributing

See CONTRIBUTING.md for ways you can contribute to Zed.

Also... we're hiring! Check out our jobs page for open roles.

Licensing

Zed source code is licensed primarily under GPL-3.0-or-later, with Apache-2.0 components where marked.

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 specified error for a crate you've created? If so, add publish = false under [package] in your crate's Cargo.toml.
  • Is the error failed to satisfy license requirements for 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 the accepted array in script/licenses/zed-licenses.toml.
  • Is cargo-about unable to find the license for a dependency? If so, add a clarification field at the end of script/licenses/zed-licenses.toml, as specified in the cargo-about book.

Sponsorship

Zed is developed by Zed Industries, Inc., a for-profit company.

If you’d like to financially support the project, you can do so via GitHub Sponsors. Sponsorships go directly to Zed Industries and are used as general company revenue. There are no perks or entitlements associated with sponsorship.

S
Description
No description provided
Readme
411 MiB
0 Stars 1 Watchers 0 Forks
Languages
Rust 94.9%
JSON-with-Comments 2.7%
Python 0.8%
Inno Setup 0.3%
Tree-sitter Query 0.3%
Other 0.5%