Skip to content

Fix #890: never emit documentSymbol entries with empty names#896

Merged
DavidObando merged 1 commit into
mainfrom
fix/issue-890-documentsymbol-empty-name
Jun 20, 2026
Merged

Fix #890: never emit documentSymbol entries with empty names#896
DavidObando merged 1 commit into
mainfrom
fix/issue-890-documentsymbol-empty-name

Conversation

@DavidObando

Copy link
Copy Markdown
Owner

Fixes #890

Root cause

The VSCode extension repeatedly logged:

[Error] Request textDocument/documentSymbol failed.
Error: name must not be falsy

SyntaxToken.IsMissing is defined as Text == null, and the parser's
MatchToken returns a token with null Text whenever an expected token is
missing. For incomplete or error declarations — e.g. func/struct/enum
with no name, or let = 42 — the identifier token is synthesized with a
null Text.

DocumentSymbolComputer.ComputeDocumentSymbols copied Identifier.Text
straight into DocumentSymbol.Name, so the textDocument/documentSymbol
response contained symbols whose name was null/empty (falsy). The
vscode-languageclient asDocumentSymbols protocol converter validates that
every symbol has a non-empty name and throws "name must not be falsy",
which breaks the Outline view and breadcrumbs for the affected file.

Fix

Guard every symbol-construction site in DocumentSymbolComputer with a new
SymbolName(SyntaxToken identifier, string fallback) helper that substitutes a
sensible, non-empty fallback name whenever the identifier token is missing,
empty, or whitespace:

  • <function>, <variable>, <struct>, <enum> for top-level declarations
  • <field>, <member> for struct fields and enum members (child symbols)

This covers every node kind the computer can emit (functions, global
variables, structs + their fields, enums + their members), so a null/empty
name can never reach the protocol layer. The fix is in the language server
source, not the bundled extension artifact.

Tests

Added regression tests in DocumentSymbolHandlerTests that:

  • assert no returned DocumentSymbol (or any child) ever has an empty/null
    name for a range of incomplete declarations, and
  • confirm valid symbols still appear with their correct names alongside
    incomplete ones.

Local build + test results

  • dotnet build GSharp.sln -c Release --no-restore -graph → succeeded, 0 errors
  • dotnet test GSharp.sln -c Release --no-build → all green:
    • LanguageServer.Tests: 335 passed
    • Core.Tests: 3340 passed (1 skipped)
    • Compiler.Tests: 1347 passed
    • Interpreter.Tests: 308 passed
    • Extensions.Tests: 104 passed
    • Sdk.Tests: 38 passed
    • 0 failures

Files changed

  • src/LanguageServer/HoverComputer.csDocumentSymbolComputer fix
  • test/LanguageServer.Tests/DocumentSymbolHandlerTests.cs — regression tests

Incomplete or error declarations (e.g. `func`/`struct`/`enum` with no name,
or `let = 42`) produce missing identifier tokens whose `Text` is null. The
language server's DocumentSymbolComputer copied that null directly into the
DocumentSymbol.Name, so the textDocument/documentSymbol response contained
symbols with falsy names. The vscode-languageclient `asDocumentSymbols`
converter validates every symbol has a non-empty name and threw
"name must not be falsy", breaking the Outline view and breadcrumbs.

Guard symbol construction with a SymbolName helper that substitutes a
sensible non-empty fallback (e.g. <function>, <struct>, <enum>, <variable>,
<field>, <member>) whenever the identifier token is missing, empty, or
whitespace. This covers every node kind the computer emits, including child
field and enum-member symbols, so a null/empty name can never be produced.

Adds regression tests asserting no DocumentSymbol (or child) ever has an
empty name for incomplete declarations, while valid symbols keep their
real names.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@DavidObando DavidObando merged commit 65aec6e into main Jun 20, 2026
7 checks passed
@DavidObando DavidObando deleted the fix/issue-890-documentsymbol-empty-name branch June 20, 2026 00:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Error in the VSCode extension: name must not be falsy

1 participant