refactor symbol handling and update tests for document symbols - #3241
Open
DaliVana wants to merge 1 commit into
Open
refactor symbol handling and update tests for document symbols#3241DaliVana wants to merge 1 commit into
DaliVana wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses the bulk of #3232 (scope notes below).
What changed
Symbol kinds are now inferred from initializer expressions. Previously every
const/vardeclaration was reported asConstant/Variablebased solely on the muttoken, so enums, structs, and imports were indistinguishable in the outline:
const E = enum {...};const S = struct {...};const U = union(enum) {...};const O = opaque {};const Error = error{...};,A || Bconst std = @import("std");test "foo" {}¹ LSP has no Union/Opaque kind; rust-analyzer maps
union→ Struct the same way.² LSP has no Test kind; rust-analyzer and gopls also report tests as plain functions.
Also applied to
workspace/symbol.Methods are distinguished from functions. A function whose first parameter type —
after stripping single-item/C pointers — is
@This(), the conventionalSelf, or theenclosing container's binding name is reported as
Method. Slices and many-itempointers are rejected since they can never be a method receiver (
[*c]is acceptedbecause
*Tcoerces to it). The binding-name rule is scope-accurate: a function in anested container taking the outer type is correctly reported as a plain function.
The
_marker of non-exhaustive enums is no longer listed as anEnumMember(a member explicitly spelled
@"_"still is).ZON files now have a document outline. Previously
textDocument/documentSymbolreturned null for
.zonfiles. The value tree is now walked with kinds mirroring theJSON language service: struct inits → Module, array inits → Array, plus
String/Number/Boolean/Null/EnumMember for scalars. Struct-init fields are named by
their
.fieldname; array elements by index (0,1, …). Trees with parse errorsreturn an empty outline (ZON Asts are unusable when the root expr has errors, same
workaround as hover/goto).
Design constraints
Known heuristic limitations (documented in code):
self: anytypereceivers are notdetected, and top-level functions of a file-as-struct (
const Self = @This()siblingbinding) are reported as
Function— most clients render Function and Method with thesame icon, so this is invisible in practice.
Not included, possible follow-ups: kind parity for
workspace/symbol(TrigramStorestill records only Constant/Variable/Function/Field), and position-asserting tests for
the ZON range synthesis.
Testing
document_symbol/workspace_symbolsexpectationsmethod detection (pointer sizes,
@This(),Self, nested and function-localcontainers), non-exhaustive enums, and four ZON outlines (build.zig.zon-style
fixture, scalars, root array, parse errors)