Sync fork with upstream zed-industries/zed

.agents/skills/gpui-test/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: gpui-test
+description: >-
+  Use when writing, debugging, or reproducing GPUI tests in Zed, including
+  gpui::test arguments, TestAppContext parameters, scheduler seeds,
+  ITERATIONS/SEED reproduction, parking failures, and pending task traces.
+---
+
+# GPUI Test Debugging
+
+Use this skill when the user asks about `#[gpui::test]`, GPUI test seeds or iterations, deterministic scheduler failures, parking/pending task failures, or how to reproduce a flaky GPUI test.
+
+## What `#[gpui::test]` does
+
+`#[gpui::test]` expands to a normal Rust `#[test]`, so it runs under standard Rust test runners such as `cargo test` and `cargo nextest`.
+
+It wraps the body in GPUI's deterministic test dispatcher/scheduler and can run the same test multiple times with different seeds. The seed controls scheduler task interleavings and any `StdRng` argument injected into the test.
+
+The macro supports both synchronous and asynchronous tests.
+
+### Supported function arguments
+
+The macro recognizes arguments by type name:
+
+| Test kind | Supported arguments |
+| --- | --- |
+| Sync and async | `&TestAppContext`, `&mut TestAppContext`, `StdRng` |
+| Async only | `BackgroundExecutor` |
+| Sync only | `&App`, `&mut App` |
+
+`StdRng` is seeded from the current GPUI test seed, and `BackgroundExecutor` is backed by the same deterministic test dispatcher.
+
+### Attribute arguments
+
+Use these forms on `#[gpui::test(arguments)]`:
+
+- No arguments: runs once with seed `0`, unless `SEED` is set.
+- `seed = N`: adds a single explicit seed.
+- `seeds(...)`: adds multiple explicit seeds.
+- `iterations = N`: runs sequential seeds starting at `0` by default.
+- `retries = N`: retries a failing run up to `N` times before surfacing the failure.
+- `on_failure = "path::to::function"`: calls the function after final failure, before resuming the panic.
+- `iterations` can be combined with explicit `seed` / `seeds`; explicit seeds are appended to the `0..iterations` range.
+- If the `SEED` environment variable is set, it takes precedence over explicit seeds.
+- With `SEED=N` and `ITERATIONS=M` or `iterations = M`, the harness runs seeds `N..N+M`.
+
+## Environment variables
+
+### GPUI test macro / scheduler execution
+
+- `SEED=<u64>` — chooses the scheduler seed. Use this to reproduce a failure printed as `failing seed: N`. It also seeds injected `StdRng` arguments. For `#[gpui::property_test]`, it controls the scheduler seed and GPUI applies it to the proptest config for deterministic case generation.
+- `ITERATIONS=<usize>` — overrides the `iterations = ...` value at runtime. Use to sweep many seeds without editing the test.
+- `PENDING_TRACES=1` or `PENDING_TRACES=true` — captures and prints pending task traces when the test scheduler panics with `Parking forbidden`. Use this when `run_until_parked()` or teardown reports pending work.
+- `GPUI_RUN_UNTIL_PARKED_LOG=1` — logs when `allow_parking()` is enabled. Use to find tests that explicitly permit parking/pending work.
+- `DEBUG_SCHEDULER=1` — prints scheduler clock/timer debugging from `scheduler::TestScheduler`.
+
+### Lower-level scheduler tests
+
+- `SCHEDULER_NONINTERACTIVE=1` — suppresses interactive seed progress output in `scheduler::TestScheduler::many`. This does not affect the `#[gpui::test]` harness path.
+
+### General Rust test debugging vars often useful with GPUI tests
+
+- `RUST_BACKTRACE=1` or `RUST_BACKTRACE=full` — show panic backtraces.
+- `RUST_LOG=<filter>` — enable logs when the test initializes logging.
+- `ZED_HEADLESS=1` — forces GPUI platform guessing toward headless mode; useful for tests that otherwise interact with platform/window setup.
+
+Prefer env vars over editing the test when narrowing a reproduction.
+
+## Reproducing a specific GPUI test
+
+1. Identify the crate/package and test name.
+
+2. Run the narrowest test filter first, skip to 3. if a failing seed is known.
+
+   ```sh
+   cargo -q test -p <crate-name> <test_name> -- --nocapture
+   ```
+
+3. If the failure mentions a seed, rerun exactly that seed.
+
+   ```sh
+   SEED=<seed> cargo -q test -p <crate-name> <test_name> -- --nocapture
+   ```
+
+4. If the failure is flaky and no seed is known, sweep seeds.
+
+   ```sh
+   ITERATIONS=100 cargo -q test -p <crate-name> <test_name> -- --nocapture
+   ```
+
+   When the harness prints `failing seed: <seed>`, switch to `SEED=<seed>` for all future debugging.
+
+5. If the failure is `Parking forbidden`, rerun with pending traces.
+
+   ```sh
+   PENDING_TRACES=1 cargo -q test -p <crate-name> <test_name> -- --nocapture
+   ```
+
+   If a failing seed was printed or is already known, include it too:
+
+   ```sh
+   SEED=<seed> PENDING_TRACES=1 cargo -q test -p <crate-name> <test_name> -- --nocapture
+   ```
+
+   Inspect the pending traces for a task that was spawned but not awaited, detached, completed, or intentionally allowed to park.
+
+6. If timing or timer advancement is involved, prefer GPUI scheduler timers in tests:
+
+   ```rust
+   cx.background_executor().timer(duration).await;
+   ```
+
+   Avoid `smol::Timer::after(...)` in GPUI tests that rely on `run_until_parked()`, because GPUI's scheduler may not track it.
+
+7. Minimize the reproduction.
+   - Keep the failing `SEED` fixed.
+   - Reduce `ITERATIONS` to `1` or remove it once a seed is known.
+   - Remove unrelated setup only after confirming the same seed still fails.
+   - Preserve scheduler-sensitive awaits/yields; removing them can mask the bug.
+   - If randomness is test-controlled via `StdRng`, log or assert the generated scenario after fixing the scheduler seed.
+
+8. Validate the fix.
+   - Run the fixed seed.
+   - Run a modest seed sweep, e.g. `ITERATIONS=20`, if the failure was scheduler-sensitive.
+   - Run the relevant crate's test filter or broader suite if the touched code has shared behavior.
+
+## Common diagnosis patterns
+
+### Seed-dependent assertion failure
+
+Likely caused by a scheduler interleaving or by `StdRng`-driven test data. Fix `SEED`, reproduce, and inspect which task or generated scenario differs.
+
+### `Parking forbidden`
+
+Usually means a foreground/background task is still pending when the scheduler expected the test to make progress or finish. Look for:
+
+- A task that should be awaited but was dropped.
+- A task that should be detached with error logging.
+- A timer or receiver that is waiting forever.
+- A missing `cx.run_until_parked()` after triggering async work in a test.
+- A missing `cx.advance_clock(...)` to wait for debounced work in a test.
+- Use of non-GPUI timers or executors that the test scheduler cannot drive.
+
+Rerun with `PENDING_TRACES=1` before changing code.
+
+### Non-determinism / wrong thread
+
+The scheduler can report activity from an unexpected thread. Look for work escaping GPUI's foreground/background executors, direct thread spawns, or external async runtimes not controlled by the test dispatcher.
+
+### Tests pass alone but fail in sweeps
+
+Use the failing seed from sweep output. Avoid assuming test order unless the runner is explicitly serial. Check globals, leaked entities/tasks, and state not reset by test initialization.
+
+## Writing GPUI tests
+
+- Prefer `#[gpui::test]` for tests that need `TestAppContext`, deterministic executors, fake time, or scheduler interleaving coverage.
+- Add `iterations = N` when the test is intentionally checking interleavings.
+- Use `StdRng` as a test argument when randomized test data should follow the same seed as the scheduler.
+- Use `cx.background_executor().timer(duration).await` for delays/timeouts in GPUI tests.
+- Do not add or increase `retries` while fixing a test unless the user explicitly asks or the test already documents why probabilistic tolerance is intentional. Retries can mask the failure instead of fixing it.

.agents/skills/lint-creator/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: lint-creator
+description: An auxiliary skill to add more dylints to `tooling/lints`
+disable-model-invocation: false
+---
+
+# Lint RULES
+
+1. Every lint MUST have accompanying `ui` tests
+2. `ui` tests MUST be in the `ui` folder
+3. Every lint MUST be in a separate module
+4. Every lint MUST have negative `ui` tests
+5. Lints should be as simple as possible.
+6. Reporting is fine if it's simple, it does not need to be elaborate or lengthy code.
+7. Do NOT suggest how to fix the lint, only flag it.
+8. Do NOT make lints machine applicable.
+9. Detect if lints are redundant vs clippy's capabilities.

.agents/skills/zed-cherry-pick/SKILL.md

@@ -0,0 +1,175 @@
+---
+name: zed-cherry-pick
+description: Cherry-pick one or more merged PRs and/or commits into Zed's `preview` or `stable` release branch. Use this whenever the user mentions cherry-picking to preview/stable, a failed cherry-pick run, or wants to manually port fix(es) into a release branch.
+---
+
+# Zed Cherry-Pick
+
+Zed ships from two long-lived release branches that live on `origin`:
+
+- `preview` channel → branch like `v1.4.x`
+- `stable` channel → branch like `v1.3.x`
+
+The version numbers change with each release. **Never hardcode them — always discover the current mapping** (see [Finding the target branch](#finding-the-target-branch)).
+
+A merged PR on `main` gets ported to a release branch by `script/cherry-pick`, normally driven by the `cherry_pick` GitHub Actions workflow. When that workflow fails (almost always a merge conflict), use this skill to finish the job locally and open the cherry-pick PR by hand.
+
+## When to use
+
+Use this when the user asks to cherry-pick one or more commits and/or Pull Requests (by number or URL) to `preview` or `stable`.
+Optionally, the user may specify whether to resolve merge conflicts; if unspecified, attempt the cherry-pick, and then if there are merge conflicts in practice, stop and inform the user that there are merge conflicts and offer to resolve them. (Users may prefer to resolve the merge conflicts themselves before continuing.)
+
+## The script you're emulating
+
+The canonical procedure lives in `script/cherry-pick` and the `cherry_pick` GitHub Actions workflow. Read the script first if anything looks off — your local steps must produce the same branch name, PR title, and PR body it would.
+
+Signature: `script/cherry-pick <branch-name> <commit-sha> <channel>`
+
+- `<branch-name>` is the release branch (e.g. `v1.4.x`), **not** the channel name.
+- `<channel>` is `preview` or `stable`, used only for display text in the PR title/body.
+
+It creates a local branch named `cherry-pick-<branch-name>-<short-sha>` (the short SHA is the first 8 chars of the commit), force-pushes it to `origin`, and opens a PR.
+
+## Finding the target branch
+
+The channel→branch mapping changes every release. Find the current one by inspecting the most recent `cherry_pick` workflow runs:
+
+```
+gh run list --workflow=cherry_pick.yml --limit 30 --json displayTitle,databaseId
+# pick a recent run for the channel you want, then:
+gh run view <id> --log 2>&1 | grep -E "BRANCH:|CHANNEL:"
+```
+
+A successful run prints both `BRANCH:` and `CHANNEL:` env vars; that's your mapping.
+
+## Procedure
+
+### 1. Gather context
+
+You need three things: the **merge commit SHA**, the **target branch**, and the **channel name**.
+
+If the user requested multiple PRs and/or commits, gather the metadata for all of them first and cherry-pick them in the order they landed on `main`, oldest to newest. For PRs, order by `mergedAt`; for raw commits, use their order on `main` when available, otherwise commit date. This tends to reduce avoidable conflicts because later changes may depend on earlier ones, but it does not guarantee a conflict-free cherry-pick when the release branch has diverged.
+
+```
+gh pr view <PR_NUMBER> --json title,number,mergeCommit,mergedAt,url
+```
+
+If the user said the workflow failed, fetch its log to see exactly which command failed and which file conflicted:
+
+```
+gh run list --workflow=cherry_pick.yml --limit 10 --json databaseId,displayTitle,status,conclusion
+gh run view <failed_run_id> --log-failed
+```
+
+The failed-run log also confirms the `BRANCH` and `COMMIT` the workflow used — handy if there's any ambiguity.
+
+### 2. Reproduce the script's setup locally
+
+The repository may be a worktree (check `.git` — if it's a file, you're in a worktree pointing at a shared gitdir). That's fine; just operate normally.
+
+```
+git --no-pager fetch origin <branch-name> <commit-sha>
+git checkout --force origin/<branch-name> -B cherry-pick-<branch-name>-<short-sha>
+git cherry-pick <commit-sha>
+```
+
+The branch name **must** match `cherry-pick-<branch-name>-<short-sha>` exactly (script convention; reviewers and tooling expect it).
+
+### 3. Check for missing prerequisite cherry-picks
+
+If the cherry-pick conflicts, do not immediately resolve the conflicts manually.
+
+First determine whether the conflict is likely caused by other PRs or commits that are already on `main` but missing from the release branch. If so, point out those candidate prerequisite PRs/commits to the user, including PR links, and offer to either resolve the conflicts manually or let the user run the GitHub cherry-pick workflow for those commits first.
+
+If the user wants to run the workflow for the missing prerequisites, stop here. This often keeps cherry-picks clean and eligible for automatic approval.
+
+Only resolve conflicts manually if:
+- no likely missing prerequisites are found, or
+- the user chooses manual conflict resolution instead of cherry-picking the prerequisites first.
+
+### 4. Resolve the conflicts manually
+
+Do this only after checking for missing prerequisite cherry-picks.
+
+- Inspect every conflicted file with `grep -n '<<<<<<<\\|>>>>>>>\\|=======' <path>` to find the markers.
+- Conflicts are usually `diff3` style with three sections: HEAD (release branch), `||||||| parent of <sha>` (merge base on `main`), and the incoming change.
+- Read the **original commit** (`git --no-pager show <commit-sha> -- <path>`) to understand the author's intent, then pick the resolution that produces the equivalent end state on the release branch.
+- Don't grab unrelated changes from `main` that happen to surround the conflict — keep the cherry-pick minimal.
+
+### 5. Validate
+
+Always build and (if reasonable) test the affected crate(s) before continuing the cherry-pick.
+
+```
+cargo check -p <affected_crate>
+cargo test  -p <affected_crate>
+```
+
+If validation fails, fix the resolution — do **not** continue with a broken build. If you can't reach a clean state, abort with `git cherry-pick --abort` and report back to the user.
+
+### 6. Finish the cherry-pick
+
+`git cherry-pick --continue` opens an editor by default. Prevent that:
+
+```
+git add <resolved_files>
+GIT_EDITOR=true git cherry-pick --continue
+```
+
+This preserves the original commit message verbatim, which is what the script does.
+
+### 7. Push and open the PR
+
+```
+git push origin -f cherry-pick-<branch-name>-<short-sha>
+```
+
+Then create the PR with the **exact** title and body format `script/cherry-pick` uses, so it's indistinguishable from an automated one.
+
+**Title:**
+
+```
+<original commit subject> (cherry-pick to <channel>)
+```
+
+The original commit subject already ends in ` (#<original_pr_number>)`; keep it.
+
+**Body** (when the original commit title ends in `(#<N>)`, which is the normal case):
+
+```
+Cherry-pick of #<original_pr_number> to <channel>
+
+----
+<original commit body, verbatim>
+```
+
+Create it with `gh pr create`, writing the body to a temp file to keep formatting intact:
+
+```
+git --no-pager log -1 --pretty=format:"%b" > /tmp/cp-body-tail.md
+printf 'Cherry-pick of #%s to %s\n\n----\n' <PR_NUMBER> <channel> | cat - /tmp/cp-body-tail.md > /tmp/cp-body.md
+gh pr create --base <branch-name> --head cherry-pick-<branch-name>-<short-sha> \\
+  --title "<commit subject> (cherry-pick to <channel>)" \\
+  --body-file /tmp/cp-body.md
+```
+
+Do **not** add a `Release Notes:` section — the original commit body already has one (or already says `N/A`), and you don't want it duplicated.
+
+## Final report to the user
+
+Tell the user:
+- The new PR URL.
+- A one-line summary of the conflict and how you resolved it.
+- What validation you ran (commands + result).
+- That their local branch is now `cherry-pick-<branch-name>-<short-sha>`, in case they want you to switch back.
+
+## Gotchas
+
+- **`--no-pager` and `GIT_EDITOR=true`**: required for non-interactive git in this environment. Forgetting `GIT_EDITOR=true` on `cherry-pick --continue` hangs the terminal.
+- **Worktree index lock**: if a previous git command was interrupted, you may see `index.lock` errors. The lock lives at `<gitdir>/index.lock` where `<gitdir>` is what `cat .git` points to (for a worktree). Remove it only if you're sure no git process is running.
+- **Don't expand the cherry-pick's scope**: when resolving conflicts, never pull in unrelated changes from `main` just because they sit next to the conflict region. The PR should be the smallest diff that reproduces the original commit's intent on the release branch.
+- **Channel branches are not called `preview`/`stable`**: don't try to `git fetch origin preview`. Look up the actual `vX.Y.x` branch name first.
+
+## When Finished
+
+After everything is finished, the last thing to do is to provide a link to the opened pull request(s) for the cherry-pick(s).

.cargo/ci-config.toml

@@ -15,14 +15,4 @@ rustflags = ["-D", "warnings"]
 [profile.dev]
 debug = "limited"
 
-# Use Mold on Linux, because it's faster than GNU ld and LLD.
-#
-# We no longer set this in the default `config.toml` so that developers can opt in to Wild, which
-# is faster than Mold, in their own ~/.cargo/config.toml.
-[target.x86_64-unknown-linux-gnu]
-linker = "clang"
-rustflags = ["-C", "link-arg=-fuse-ld=mold"]
 
-[target.aarch64-unknown-linux-gnu]
-linker = "clang"
-rustflags = ["-C", "link-arg=-fuse-ld=mold"]

.cargo/config.toml

@@ -16,5 +16,9 @@ rustflags = [
     "target-feature=+crt-static", # This fixes the linking issue when compiling livekit on Windows
 ]
 
+# We need lld to link libwebrtc.a successfully on aarch64-linux
+[target.aarch64-unknown-linux-gnu]
+rustflags = ["-C", "link-arg=-fuse-ld=lld"]
+
 [env]
 MACOSX_DEPLOYMENT_TARGET = "10.15.7"

.cloudflare/README.md

@@ -4,11 +4,11 @@ from Cloudflare.
 - `open-source-website-assets` is used for `install.sh`
 - `docs-proxy` is used for `https://zed.dev/docs`
 
-On push to `main`, both of these (and the files they depend on) are uploaded to Cloudflare.
+During docs deployments, both of these (and the files they depend on) are uploaded to Cloudflare.
 
 ### Deployment
 
-These functions are deployed on push to main by the deploy_cloudflare.yml workflow. Worker Rules in Cloudflare intercept requests to zed.dev and proxy them to the appropriate workers.
+These functions are deployed by the docs deployment workflows. Worker Rules in Cloudflare intercept requests to zed.dev and proxy them to the appropriate workers.
 
 ### Testing