This PR reverts #17173, as it introduced a segfault when opening any
Gleam project and the language server starts up.
This reverts commit a850731b0e.
Release Notes:
- N/A
Context: https://x.com/fasterthanlime/status/1819120238228570598
Up to this PR:
- We were not watching paths outside of a worktree when language server
requested it.
- We expected GlobPattern used for file watching to be always rooted at
the worktree root.
'1 mattered for observing global files (e.g. global RA config) and both
points had impact on "monorepos".
Let's picture the following scenario:
You're working on a Rust project that has two crates: bin and lib crate:
```
my-rust-project/
bin-crate/
lib-crate/
```
Up to this PR, making changes like changing field visibility in
lib-crate **was not reflected** in bin-crate until RA was restarted. RA
for bin-crate asked us to watch lib-crate. Now, depending on if you had
this project open as:
- a project with one worktree rooted at my-rust-project:
- due to '2, we never noticed that we have to notify RA instance for
bin-crate about changes in lib-crate.
- a project with two worktrees (bin-crate and lib-crate):
- due to '1 (as lib-crate is not within bin-crate's worktree), we once
again missed the fact that we have to watch for changes in lib-crate.
This PR solves this by introducing a side-channel - we just store fs
watchers for abs paths at the Project level. Worktree changes handling
is left relatively untouched - as it's used for other changes besides
LSP change notifying, I've figured to better leave it as is, as right
now we have 1 worktree change watcher; if we were to change it, we'd
have `(language server) + 1` watchers per worktree, which seems.. pretty
horrid.
What's the end effect? At the very least fasterthanlime should be a tad
happier; in reality though, I expect it to have some impact on LS
reliability in monorepo setups.
TODO
- [x] Wire through FileChangeType into `fs::watch` interface.
Release Notes:
- Improved language server reliability in multi-worktree projects and
monorepo. We now notify the language server more reliably about which
files have changed.
For ssh remoting lsps we'll need to have language server support
factored out of project.
Thus that begins
Release Notes:
- N/A
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Mikayla <mikayla@zed.dev>
This PR makes the `github_user_created_at` field required at ingress
points into collab.
In practice we already have this value passed up, this change just makes
that explicit.
This is a precursor to making it required in the database.
Release Notes:
- N/A
Co-Authored-By: Mikayla <mikayla@zed.dev>
Co-Authored-By: Nate <nate@zed.dev>
Closes#15606Closes#13515
Release Notes:
- Fixes `-` being considered a word character for selections in some
languages
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Nate <nate@zed.dev>
This PR updates the Assistant with support for receiving tool uses from
Anthropic models and capturing them as text in the context editor.
This is just laying the foundation for tool use. We don't yet fulfill
the tool uses yet, or define any tools for the model to use.
Here's an example of what it looks like using the example `get_weather`
tool from the Anthropic docs:
<img width="644" alt="Screenshot 2024-08-30 at 1 51 13 PM"
src="https://github.com/user-attachments/assets/3614f953-0689-423c-8955-b146729ea638">
Release Notes:
- N/A
This PR removes the `cache_control` field from the variants in
`ResponseContent`.
This field is used on requests to control the caching behavior, but is
not needed on content in the response.
Release Notes:
- N/A
This PR splits the `Content` type for Anthropic into two new types:
`RequestContent` and `ResponseContent`.
As I was going through the Anthropic API docs it seems that there are
different types of content that can be sent in requests vs what can be
returned in responses.
Using a separate type for each case tells the story a bit better and
makes it easier to understand, IMO.
Release Notes:
- N/A
I have found an error running tests in Golang projects that use
submodules. This PR fixes the issue by accessing the directory before
running the test.
The `commons` in the image is a git submodule in a subfolder inside a
parent folder where the workspace is set.
Release Notes:
- Fixed Go tests not being able to run in case the package (and the
`go.mod`) was in a nested folder. Pre-defined Go tasks have been changed
to now run in the package's directory. That means `go test ./package
-run MyTest` will run in `./package` and execute `go test -run MyTest`.
Also, `go test ./...` will run in the package directory, not at the root
of the Zed project, which is a small breaking change. In case one wants
to run `go test ./...` from the root, one can spawn a manual task that
does this.
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
Fixes this weird behavior:
- open an file, like `test.rs`
- `ctrl-n` create an new buffer
- `ctrl-s` save new buffer with name `test.rs`, select replace old file.
- the older open file also exist, this is weird.
Release Notes:
- Fixed two panes staying opening when saving a new buffer with the same filename as a file that was already open.
**Changelog:**
- Replace default tasks with a stub message (#16752)
- Update tree-sitter grammar for the Ruby language (#16892)
- Rename `rbs` to `RBS` (#16893)
- Upgrade `zed_extension_api` to v0.1.0 (#16907)
Release Notes:
- N/A
This fixes a bug that I've been running into for quite a while:
- Open a new terminal inside Zed
- (Center pane loses focus)
- (Workspace is serialized)
- Quit Zed
- Open Zed
- (Workspace is deserialized without an active pane)
- Put cursor in assistant panel
- Try to use `ActivatePaneInDirection` to go to the center
- Does not work
So what this fix does is to ensure that in case the pane does become
focused, even though it was already marked as focused, the active center
pane is set.
It also adds a fallback when trying to get the last active pane.
Release Notes:
- Fixed an issue where `workspace::ActivatePaneInDirection` could not
activate the center pane (i.e. one couldn't navigate from terminal or
assistant panel to the center pane) after loading Zed.
This reverts commit 9206561662.
It lead to this panic:
```
Thread "main" panicked with "invalid SecondaryMap key used" at /Users/thorstenball/work/zed/crates/gpui/src/app/entity_map.rs:120:22
0: backtrace::backtrace::libunwind::trace
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/backtrace/libunwind.rs:116:5
backtrace::backtrace::trace_unsynchronized::<<backtrace::capture::Backtrace>::create::{closure#0}>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/backtrace/mod.rs:66:5
1: backtrace::backtrace::trace::<<backtrace::capture::Backtrace>::create::{closure#0}>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/backtrace/mod.rs:53:14
2: <backtrace::capture::Backtrace>::create
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/capture.rs:197:9
3: <backtrace::capture::Backtrace>::new
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/capture.rs:162:22
4: zed::reliability::init_panic_hook::{closure#0}
at /Users/thorstenball/work/zed/crates/zed/src/reliability.rs:58:29
5: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/alloc/src/boxed.rs:2077:9
std::panicking::rust_panic_with_hook
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:799:13
6: std::panicking::begin_panic::<&str>::{closure#0}
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:694:9
7: std::sys_common::backtrace::__rust_end_short_backtrace::<std::panicking::begin_panic<&str>::{closure#0}, !>
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/sys_common/backtrace.rs:171:18
8: std::panicking::begin_panic::<&str>
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:693:12
9: <slotmap::secondary::SecondaryMap<gpui::app::entity_map::EntityId, alloc::boxed::Box<dyn core::any::Any>> as core::ops::index::Index<gpui::app::entity_map::EntityId>>::index
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/slotmap-1.0.7/src/secondary.rs:866:21
10: <gpui::app::entity_map::EntityMap>::read::<vim::Vim>
at /Users/thorstenball/work/zed/crates/gpui/src/app/entity_map.rs:120:22
11: <gpui::app::entity_map::Model<vim::Vim>>::read
at /Users/thorstenball/work/zed/crates/gpui/src/app/entity_map.rs:397:9
12: <gpui::view::View<vim::Vim>>::read
at /Users/thorstenball/work/zed/crates/gpui/src/view.rs:81:9
13: <vim::VimAddon as editor::Addon>::should_show_inline_completions
at /Users/thorstenball/work/zed/crates/vim/src/vim.rs:138:20
14: <editor::Editor>::should_show_inline_completions
at /Users/thorstenball/work/zed/crates/editor/src/editor.rs:2347:21
15: <editor::Editor>::refresh_inline_completion
at /Users/thorstenball/work/zed/crates/editor/src/editor.rs:4988:17
16: <editor::Editor>::undo
at /Users/thorstenball/work/zed/crates/editor/src/editor.rs:6868:13
17: vim::normal::register::{closure#7}::{closure#0}
at /Users/thorstenball/work/zed/crates/vim/src/normal.rs:176:17
18: <vim::Vim>::update_editor::<(), vim::normal::register::{closure#7}::{closure#0}>::{closure#0}
at /Users/thorstenball/work/zed/crates/vim/src/vim.rs:693:45
19: <gpui:🪟:WindowContext as gpui::VisualContext>::update_view::<editor::Editor, (), <vim::Vim>::update_editor<(), vim::normal::register::{closure#7}::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:3890:22
20: <gpui:🪟:ViewContext<vim::Vim> as gpui::VisualContext>::update_view::<editor::Editor, (), <vim::Vim>::update_editor<(), vim::normal::register::{closure#7}::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:4522:9
21: <gpui::view::View<editor::Editor>>::update::<gpui:🪟:ViewContext<vim::Vim>, (), <vim::Vim>::update_editor<(), vim::normal::register::{closure#7}::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/view.rs:76:9
22: <vim::Vim>::update_editor::<(), vim::normal::register::{closure#7}::{closure#0}>
at /Users/thorstenball/work/zed/crates/vim/src/vim.rs:693:14
23: vim::normal::register::{closure#7}
at /Users/thorstenball/work/zed/crates/vim/src/normal.rs:174:9
24: <gpui:🪟:ViewContext<vim::Vim>>::listener::<vim::normal::Undo, vim::normal::register::{closure#7}>::{closure#0}::{closure#0}
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:4444:40
25: <gpui:🪟:WindowContext as gpui::VisualContext>::update_view::<vim::Vim, (), <gpui:🪟:ViewContext<vim::Vim>>::listener<vim::normal::Undo, vim::normal::register::{closure#7}>::{closure#0}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:3890:22
26: <gpui::view::View<vim::Vim>>::update::<gpui:🪟:WindowContext, (), <gpui:🪟:ViewContext<vim::Vim>>::listener<vim::normal::Undo, vim::normal::register::{closure#7}>::{closure#0}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/view.rs:76:9
27: <gpui::view::WeakView<vim::Vim>>::update::<gpui:🪟:WindowContext, (), <gpui:🪟:ViewContext<vim::Vim>>::listener<vim::normal::Undo, vim::normal::register::{closure#7}>::{closure#0}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/view.rs:192:12
28: <gpui:🪟:ViewContext<vim::Vim>>::listener::<vim::normal::Undo, vim::normal::register::{closure#7}>::{closure#0}
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:4444:13
29: <editor::Editor>::register_action::<vim::normal::Undo, <gpui:🪟:ViewContext<vim::Vim>>::listener<vim::normal::Undo, vim::normal::register::{closure#7}>::{closure#0}>::{closure#0}::{closure#0}
at /Users/thorstenball/work/zed/crates/editor/src/editor.rs:12053:25
30: <gpui:🪟:WindowContext>::dispatch_action_on_node
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:3514:21
31: <gpui:🪟:WindowContext>::dispatch_key_event
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:3303:13
32: <gpui:🪟:WindowContext>::dispatch_event
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:3131:13
33: <gpui:🪟:Window>:🆕:{closure#10}::{closure#0}
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:776:46
34: <gpui::app::AppContext as gpui::Context>::update_window::<gpui:🪟:DispatchEventResult, <gpui:🪟:Window>:🆕:{closure#10}::{closure#0}>::{closure#0}
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:1396:26
35: <gpui::app::AppContext>::update::<core::result::Result<gpui:🪟:DispatchEventResult, anyhow::Error>, <gpui::app::AppContext as gpui::Context>::update_window<gpui:🪟:DispatchEventResult, <gpui:🪟:Window>:🆕:{closure#10}::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:362:22
36: <gpui::app::AppContext as gpui::Context>::update_window::<gpui:🪟:DispatchEventResult, <gpui:🪟:Window>:🆕:{closure#10}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:1387:9
37: <gpui::app::async_context::AsyncAppContext as gpui::Context>::update_window::<gpui:🪟:DispatchEventResult, <gpui:🪟:Window>:🆕:{closure#10}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app/async_context.rs:91:9
38: <gpui:🪟:AnyWindowHandle>::update::<gpui::app::async_context::AsyncAppContext, gpui:🪟:DispatchEventResult, <gpui:🪟:Window>:🆕:{closure#10}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:4750:9
39: <gpui:🪟:Window>:🆕:{closure#10}
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:775:17
40: <alloc::boxed::Box<dyn core::ops::function::FnMut<(gpui::interactive::PlatformInput,), Output = gpui:🪟:DispatchEventResult>> as core::ops::function::FnMut<(gpui::interactive::PlatformInput,)>>::call_mut
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/alloc/src/boxed.rs:2070:9
41: gpui::platform::mac:🪟:handle_key_event
at /Users/thorstenball/work/zed/crates/gpui/src/platform/mac/window.rs:1300:32
42: gpui::platform::mac:🪟:handle_key_down
at /Users/thorstenball/work/zed/crates/gpui/src/platform/mac/window.rs:1212:5
43: <unknown>
44: <unknown>
45: <unknown>
46: <unknown>
47: <unknown>
48: <() as objc::message::MessageArguments>::invoke::<()>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc-0.2.7/src/message/mod.rs:128:17
49: objc::message::platform::send_unverified::<objc::runtime::Object, (), ()>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc-0.2.7/src/message/apple/mod.rs:27:9
50: objc::message::send_message::<objc::runtime::Object, (), ()>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc-0.2.7/src/message/mod.rs:178:5
<*mut objc::runtime::Object as cocoa::appkit::NSApplication>::run
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cocoa-0.26.0/src/appkit.rs:628:9
51: <gpui::platform::mac::platform::MacPlatform as gpui::platform::Platform>::run
at /Users/thorstenball/work/zed/crates/gpui/src/platform/mac/platform.rs:427:13
52: <gpui::app::App>::run::<zed::main::{closure#3}>
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:159:9
53: zed::main
at /Users/thorstenball/work/zed/crates/zed/src/main.rs:439:5
54: <fn() as core::ops::function::FnOnce<()>>::call_once
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/ops/function.rs:250:5
55: std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/sys_common/backtrace.rs:155:18
56: std::rt::lang_start::<()>::{closure#0}
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/rt.rs:159:18
57: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/ops/function.rs:284:13
std::panicking::try::do_call
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:559:40
std::panicking::try
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:523:19
std::panic::catch_unwind
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panic.rs:149:14
std::rt::lang_start_internal::{{closure}}
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/rt.rs:141:48
std::panicking::try::do_call
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:559:40
std::panicking::try
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:523:19
std::panic::catch_unwind
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panic.rs:149:14
std::rt::lang_start_internal
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/rt.rs:141:20
58: std::rt::lang_start::<()>
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/rt.rs:158:17
59: _main
```
Release Notes:
- N/A
This fixes an annoying bug I ran into, where supermaven completions
would show up in normal mode.
cc @ConradIrwin not sure if this is the best way to fix this, but it
seems like the neatest? On one hand, I didn't want to touch into Vim
from the editor, and on the other I didn't want to add another boolean
on the editor that flips on when in normal mode. So instead I extended
the Addon interface.
Release Notes:
- Fixed inline completions (Copilot or Supermaven) showing up in Vim's
normal mode.
Context servers might return CR characters, which are not acceptable in
Zed and cause ranges to be invalidated. We need to normalize them.
Closes#17109
Release Notes:
- context_servers: Fixed an issue where context servers returning a
carriage return character would result in a panic.
This PR adds support for completions via MCP. The protocol now supports
a new request type "completion/complete"
that can either complete a resource URI template (which we currently
don't use in Zed), or a prompt argument.
We use this to add autocompletion to our context server slash commands!
https://github.com/user-attachments/assets/08c9cf04-cbeb-49a7-903f-5049fb3b3d9f
Release Notes:
- context_servers: Added support for argument completions for context
server prompts. These show up as regular completions to slash commands.
This PR adds an initial set of default colors to `gpui`.
These will power default-styled gpui components (things like checkboxes,
buttons, inputs, etc.), storybook, and give a very simple,
appearance-aware set of colors out of the box for folks to build with.
These colors will evolve and be updated in the near future, they are
literally pulled from Finder for now :)
The API might not be perfect, I focused on getting something in quickly
that we can iterate on!
### Usage
```rs
use gpui::{colors, DefaultColor}
fn auto(cx: &WindowContext) -> {
// Init the full set of DefaultColors
let colors = colors(cx.appearance());
// Use a color
// It will automatically give you the correct color for the system's
// current appearance.
let background = DefaultColor::Background.hsla(&colors)
}
fn manual() -> {
// Init the full sets of DefaultColors
let light_colors = DefaultColors::light();
let dark_colors = DefaultColors::dark();
// Use a color
// Maybe for some fancy inverted element
let background = DefaultColor::Background.hsla(&light_colors)
let inverted_background = DefaultColor::Background.hsla(&dark_colors)
let inverted_text = DefaultColor::Text.hsla(&dark_colors)
}
```
Note: We need `cx` for the auto way as we need to get the system
appearance from the App/Window/ViewContext via `cx.appearance()`.
### Example
You can run `script/storybook default_colors` to open the Default Colors
story:
| Light | Dark |
|-------|------|
| 
| 
|
Release Notes:
- N/A
/cc @mrnugget
Release Notes:
- Fixed an issue where toggling inline completions in a markdown file
did not work correctly
---------
Co-authored-by: Marshall <marshall@zed.dev>
- Fixes incorrect shorcuts being displayed in Linux context menus.
- Re-ordering them within the json object doesn't work, but putting them in a dedicate block does.
The Ruby world has many testing frameworks:
- Minitest
- RSpec
- quickdraw
- tldr
- and many others.
Attempting to support all of them through a single `tasks.json` file is
a challenging task and nearly impossible. All testing frameworks have
different running options and commands. It's still possible to use
tree-sitter queries to detect runnables in Ruby code but Zed lacks the
ability to detect the testing framework in a project that can be used to
detect the correct commands to run tests or runnables. The end user
knows the correct command and it's wise to delegate creating the command
to them. It would be a bit strange to leave the user without any
guidance, so this commit adds example tasks for various Ruby testing
frameworks.
Closes#12579
Here is the screenshot how it looks:
Release Notes:
- N/A
## Todo
* [x] Parse and present new XML output
* [x] Resolve new edits to buffers and anchor ranges
* [x] Surface resolution errors
* [x] Steps fail to resolve because language hasn't loaded yet
* [x] Treat empty `<symbol>` tag as None
* [x] duplicate assists when editing steps
* [x] step footer blocks can appear *below* the following message header
block
## Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Peter <peter@zed.dev>
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
This changes the Zed CLI `zed` to pass along the environment to the Zed
project that it opens (if it opens a new one).
In projects, this CLI environment will now take precedence over any
environment that's acquired by running a login shell in a projects
folder.
The result is that `zed my/folder` now always behaves as if one would
run `zed --foreground` without any previous Zed version running.
Closes#7894Closes#16293
Related issues:
- It fixes the issue described in here:
https://github.com/zed-industries/zed/issues/4977#issuecomment-2305272027
Release Notes:
- Improved the Zed CLI `zed` to pass along the environment as it was on
the CLI to the opened Zed project. That environment is then used when
opening new terminals, spawning tasks, or language servers.
Specifically:
- If Zed was started via `zed my-folder`, a terminal spawned with
`workspace: new terminal` will inherit these environment variables that
existed on the CLI
- Specific language servers that allow looking up the language server
binary in the environments `$PATH` (such as `gopls`, `zls`,
`rust-analyzer` if configured, ...) will look up the language server
binary in the CLI environment too and use that environment when starting
the process.
- Language servers that are _not_ found in the CLI environment (or
configured to not be found in there), will be spawned with the CLI
environment in case that's set. That means users can do something like
`RA_LOG=info zed .` and it will be picked up the rust-analyzer that was
spawned.
Demo/explanation:
https://github.com/user-attachments/assets/455905cc-8b7c-4fc4-b98a-7e027d97cdfa
This PR attaches the `geoip_country_code` that we source from
Cloudflare's `CF-IPCountry` header to the HTTP request spans.
This will allow us to see where traffic is originating geographically.
Release Notes:
- N/A
- Cloudflare provides ISO-3166-1 country code for protectorates. Expand our allowlist to include the territories of countries on the allowlist (US, UK, France, Australia, New Zealand).
- Also include the country_code in the error message when we block.
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
- Remove "-" from word_character for CSS/JS/TSX/Markdown
- Makes our word-selection behavior consistent across language modes (and consistent with VSCode).
This test was flaky because both tasks were started at the same time and
the first one that would win, would navigate the editor.
Now the order is fixed, because the second task is only spawned after
the first one.
Release Notes:
- N/A
---------
Co-authored-by: Kirill <kirill@zed.dev>
This PR reverts the `clickhouse` upgrade from #17034.
After testing in staging I'm seeing errors when trying to write events
to Clickhouse. Going to revert so we can investigate.
This reverts commit 505675c0b5.
Release Notes:
- N/A
