# Objective
- Fix PowerShell discovery when Scoop is installed outside the default
`%USERPROFILE%\scoop` directory.
- Zed currently ignores Scoop's `SCOOP` environment variable, so it can
miss `pwsh.exe` and fall back to another shell.
## Solution
- Use the `SCOOP` environment variable as the Scoop root when it is set.
- Fall back to `%USERPROFILE%\scoop` when `SCOOP` is unset.
- Preserve the PowerShell discovery order and file validation from the
current `main` branch.
The original change also covered Git Bash. That is no longer needed
after #63339 changed Git Bash discovery to follow the active Git
installation.
## Testing
- `cargo fmt --all --check`
- `cargo test -p gpui_util` — 2 passed, 0 failed.
- `cargo check -p gpui_util --tests --target x86_64-pc-windows-msvc` —
passed.
- Did not runtime-test the Windows-specific path on this macOS host
because Windows test binaries cannot run natively here.
- To test manually on Windows, set `SCOOP` to a custom Scoop root
containing `shims\pwsh.exe`, launch Zed, and verify that PowerShell is
selected.
## 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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed PowerShell installed by Scoop not being detected when Scoop uses
a custom installation directory.
- [GPUI] Fixed PowerShell discovery for custom Scoop installations on
Windows.
Signed-off-by: jliu666 <jliu666@hotmail.com>
Also updates CI to always run this - that way we ensure that disabling
or enabling tests does not become stale at some point and thus can
safely add this.
Release Notes:
- N/A
- [GPUI] N/A
I think this is the final attempt of mine to do anything about the
binary size, as those fixes become relatively intricate and I like them
less and less.
Each commit has its own improvement stats and mainly reduce generic-code
duplication through shared non-generic helpers and `#[inline(never)]`
boundaries.
Total reduction stats:
With sccache disabled, `cargo clean` and `cargo build --release -p zed`:
Before: zed binary 396716472 bytes
After: zed binary 359416504 bytes (-9.40%, -37.29MB)
Release Notes:
- N/A
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Relicenses `zlog`, `ztracing`, and `ztracing_macro` from
GPL-3.0-or-later to Apache-2.0.
GPUI depends on `ztracing`, which depends on `zlog`, so these crates
have to be non-copyleft for GPUI to ship as a permissively licensed
project.
- Switched the `license` field to `Apache-2.0` in all three manifests.
- Added the `LICENSE-APACHE` symlink to `zlog`, and dropped the
`LICENSE-GPL` symlinks from all three. `ztracing` and `ztracing_macro`
already carried both symlinks; now the on-disk license matches the
manifest.
- Declared `license = "Apache-2.0"` for `gpui_util`, which had a
`LICENSE-APACHE` symlink but no `license` field. `script/check-licenses`
doesn't catch that, since it only inspects symlinks.
No source changes; none of these crates carry GPL headers or in-source
license references.
Checked the rest of the subtree while here: the only first-party crates
reachable from `ztracing` via `cargo tree -e normal` are `collections`,
`gpui_util`, `zlog`, and `ztracing_macro`, all Apache-2.0 now.
Third-party deps (`tracing`, `tracing-subscriber`, `chrono`, `log`,
`anyhow`, `tracy-client`) are MIT/Apache.
`script/check-licenses` passes.
Release Notes:
- N/A
- Simplify PowerShell discovery, and add support for .NET global tool
installations.
- Fix Git Bash discovery in the case where Zed was launched from within
Git Bash. Git Bash prepends its internal `mingw64\bin` directory to
`PATH`, so `which git` returns a different `bash` executable that causes
the relative path lookup to fail.
Release Notes:
- N/A
# Objective
Tiny annoyance, the standalone `gpui_util::log_err` was never annotated
with `#[track_caller]` so whenever it was called, the source location
would be `gpui_util::lib` instead of the appropriate location.
I checked and this is actually used in Zed in exactly one place:
`crates/extension_host/src/extension_host.rs:1095`. So *technically*
this can be considered a bug.
I use it quite frequently in my code, so this is more of a self-serving
pr.
## Solution
I added `#[track_caller]` to `gpui_util::log_err`.
## Testing
I ran the tests just in case and they all passed.
## 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:
- Added track_caller to gpui_util::log_err
This removes gpui's dependency on the `util` crate, which depends on
async process. It now depends on `gpui_util` only, and uses
`std::process::Command` for the two cases where it was previously using
an async `Command`. This lifts the requirement of non-Zed consumers of
gpui to depend on our forked async-process (see #59156).
Release Notes:
- N/A
TypeId is effectively already a hash, so re-hashing it with fxhash is
unnecessary.
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
No, sadly, the title is not a typo. See
https://www.githubstatus.com/incidents/zsg1lk7w13cf for the context.
I'll read with joy and popcorn through that root cause analysis.
It makes literally zero sense what happened here, but for some completly
bonkers reason GitHub completely messed up the merge queue with
https://github.com/zed-industries/zed/pull/54632.
I have no idea how it happened. It makes literally zero sense. A PR
going into the merge queue should have the same LoC when getting out of
it. GitHub obviously does not check this. GitHub causes extra work with
a feature that is supposed to save time.
Thanks, I guess.
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This PR brings back the button to filter remote branches when accessing
the title bar's branch picker with the mouse. It was unintentionally
removed when we introduced the new worktree picker.
Release Notes:
- N/A
Implements a basic web platform for the wasm32-unknown-unknown target
for gpui
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: John Tur <john-tur@outlook.com>
jliu666