editor: Fix LSP extension commands failing at end of file

[florian-trehaut]

Context

Closes #51330

When the cursor is at the very end of a file, find_specific_language_server_in_selection in crates/editor/src/lsp_ext.rs silently skips the selection because the anchor's buffer_id is None. This causes editor: switch source header (clangd) and rust-analyzer extension commands (expand macro, open docs, open playground) to do nothing.

The fix falls back to the singleton buffer's ID when the anchor has no buffer_id.

How to Review

Single file change in crates/editor/src/lsp_ext.rs. The diff is small — pre-compute the singleton buffer ID, then use it as fallback in the filter_map closure. An integration test verifies the fix.

Self-Review Checklist

• Reviewed own diff for quality, security, and reliability
• No unsafe blocks
• Tests pass (639 editor tests, 0 failures)
• Manual testing: switch source header works at beginning, middle, and end of C++ file

Test Plan

• New integration test: test_find_language_server_at_end_of_file — verifies find_specific_language_server_in_selection returns Some at both beginning and end of file
• Confirmed the test fails without the fix (assertion on "should find language server at end of file")
• Manual: open a C++ file with clangd, place cursor at very end, run switch source header — now correctly opens the header
• Manual: verify it still works at beginning and middle of file (non-regression)
• cargo test -p editor — 639 passed, 0 failed

Release Notes:

• Fixed editor: switch source header and other LSP extension commands not working when the cursor is at the very end of a file.

[SomeoneToIgnore]

Thank you for the fix, this is a very nice catch overall meaning there's a lot of places like this elsewhere.
The most important one most probably is the diagnostics-related code as there were reports of diagnostics not shown on the very edge of the file?

Either way, let's adjust the code for a proper multi buffer coordinate contract find_specific_language_server_in_selection exposes and merge this.

[florian-trehaut]

Thanks for taking the time to review this! I've addressed all the feedback:

• Replaced resolve_anchor_to_buffer with MultiBufferSnapshot::buffer_id_for_anchor, which already handles buffer_id: None through excerpt_containing internally
• Merged everything into a single find_map with a scoped block to avoid borrow checker issues with cx
• Kept the tail fallback
• Strengthened test assertions: server ID, language, buffer identity, file presence, all in a shared closure

About the diagnostics code you mentioned, I'd be happy to look into that as a follow-up if you can point me to the relevant area.

[SomeoneToIgnore]

Thank you, I have pushed another small fix on top to avoid extra snapshot-related creation costs.

---

I've rechecked the diagnostics-related idea of mine and that does not seem related to this particular issue: #22473

Yet, I think if you check for text_anchor.buffer_id field usages, some of them may come out wrong, e.g.

zed/crates/editor/src/document_symbols.rs

Lines 85 to 88 in 6332655

	if Some(buffer_id) != cursor.text_anchor.buffer_id {
	return None;
	}
	let buffer = self.buffer.read(cx).buffer(buffer_id)?;

or even

zed/crates/multi_buffer/src/multi_buffer.rs

Lines 2386 to 2399 in 6332655

	pub fn text_anchor_for_position<T: ToOffset>(
	&self,
	position: T,
	cx: &App,
	) -> Option<(Entity<Buffer>, language::Anchor)> {
	let snapshot = self.read(cx);
	let anchor = snapshot.anchor_before(position);
	let buffer = self
	.buffers
	.get(&anchor.text_anchor.buffer_id?)?
	.buffer
	.clone();
	Some((buffer, anchor.text_anchor))
	}

are quite suspicious already.