project: Match document filter patterns in dynamic registrations

[aviatesk]

Summary

Follow-up to #59243, which made dynamically registered capabilities honor the language and scheme of their document selectors, but left pattern matching fail-open. A registration such as { "language": "toml", "pattern": "**/Project.toml" } therefore still applied to every TOML document the server had opened, and a pattern-only filter applied to every document.

This matches pattern against the document's path:

• String patterns are matched against the absolute path. As in the LSP glob syntax, * and ? do not match path separators.
• Relative patterns are matched against the path relative to their base URI, and Zed now advertises the textDocument.filters.relativePatternSupport client capability.
• Documents without a file system path never match a pattern filter. Contexts that stand for a whole language, like the semantic token legend lookup, and guest buffers whose path is unknown keep not evaluating patterns.
• Registrations whose patterns are not valid globs are rejected when they are registered.

LSP 3.18 changed TextDocumentFilter.pattern from a string to a GlobPattern, so that it can also be a relative pattern. This PR depends on zed-industries/lsp-types#16, which updates the type and adds the client capability. I'd like to merge this together with that upstream change: Cargo.toml currently points at the commit of zed-industries/lsp-types#16 on my fork, and I will switch it to the zed-industries/lsp-types revision once that PR is merged.

Update: zed-industries/lsp-types#16 has been merged, and Cargo.toml now points at its zed-industries/lsp-types revision (zed-industries/lsp-types@82d7fc6).

Testing

• Added unit tests for matching string patterns, wildcards across path separators, and relative patterns.
• Added an integration test that a pattern-scoped completion registration only applies to matching buffers, and that a registration with an invalid pattern is rejected.
• Updated test_dynamic_formatting_registration_with_pattern_only_selector, which asserted the fail-open behavior left by lsp: Honor dynamic LSP document selectors #59243.

Self-review

• I've reviewed my diff for quality, security, reliability, and performance.
• UI changes follow the checklist.
• Tests cover the new or changed behavior.

Release Notes:

• Fixed language servers' dynamically registered capabilities applying to files outside of the pattern of their document selector.

[SomeoneToIgnore]

Thanks, this one seems relatively ready, left 2 notes.

[aviatesk]

Q. This PR’s relative patterns can make older collaboration guests fail to deserialize the entire LSP capabilities payload. Should we preserve wire compatibility here, add a CURRENT_PROJECT_FEATURES marker, or leave this case unsupported?

[SomeoneToIgnore]

Let's assume we can ignore the collab compatibility issues for now, and focus on the PR implementation, as there are things to tackle before.

[SomeoneToIgnore]

Drive-letter case is still handled only for relative bases.
With the PR’s exact matcher, the selector c:/repo/a.rs does not match the Windows document C:\repo\a.rs, since candidate normalization preserves C: and this branch uses the case-sensitive regex directly.
VS Code instead matches against Uri.fsPath, whose drive-prefix conversion lowercases the drive letter.

For a dynamically registered provider with no static counterpart, the registration is therefore still excluded by capability filtering.
We seem to need a consistent drive-prefix representation for absolute matching too, while preserving the rest of the pattern’s case sensitivity.

[SomeoneToIgnore]

The Windows base comparison is still ASCII-only.
With the PR’s exact matcher:

Base URI	Pattern	Document	Expected	Actual
file:///C:/%C3%89quipe	a.rs	C:\équipe\a.rs	Match	No match

eq_ignore_ascii_case cannot equate É and é, whereas VS Code’s comparison handles this non-ASCII case difference.
This excludes an otherwise applicable dynamic registration through capability filtering.

Use a Unicode-aware prefix comparison and derive the remaining path from the matched candidate prefix rather than the base’s UTF-8 byte length.
Case-equivalent strings need not have equal UTF-8 lengths; for example, K and k occupy three bytes and one byte respectively.

[SomeoneToIgnore]

Consecutive trailing globstars lose the final filename match:

Pattern	Document	Expected by LSP	Actual
/root/**	/root/a.rs	Match	Match
/root/**/**	/root/a.rs	Match	No match

The first ** is compiled as nonterminal, then the terminal ** is skipped as a duplicate, leaving a regex that requires a trailing separator.
The LSP definition allows each ** to match zero or more path segments, so the second selector should not lose applicability for this file.

This also reproduces in VS Code’s parser, so it is a spec-conformance gap rather than a VS Code compatibility regression.
If LSP semantics are the target, collapse consecutive globstars before deciding which one is terminal; if exact VS Code behavior is the target, this needs to be an explicit compatibility exception.

[SomeoneToIgnore]

Removing a literal / from the class does not prevent a negated class or a range from consuming a separator.
With the PR’s exact matcher:

Pattern	Document	Expected by LSP	Actual
**/a[!x]b.rs	/root/a/b.rs	No match	Match
**/a[.-0]b.rs	/root/a/b.rs	No match	Match

The emitted [^x] and [\.-0] both match /, allowing the registration to apply across a directory boundary even though LSP character classes match within a path segment.

VS Code’s parser has the same result here, so this is another spec-versus-compatibility decision rather than a divergence from VS Code.
For LSP semantics, intersect the completed class with the non-separator character set instead of only removing literal separators while parsing it.