Skip to content

feat: Add csharp support#106

Open
unliftedq wants to merge 1 commit intojustrach:mainfrom
unliftedq:add-csharp-support
Open

feat: Add csharp support#106
unliftedq wants to merge 1 commit intojustrach:mainfrom
unliftedq:add-csharp-support

Conversation

@unliftedq
Copy link
Copy Markdown
Contributor

As title, Added basic C# support to the explorer.

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 590d12dd36

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment on lines +1157 to +1160
if (std.mem.indexOf(u8, stripped, "(")) |paren| {
if (paren > 0) {
// Skip control flow keywords
const control = [_][]const u8{ "if ", "if(", "else ", "for ", "for(", "foreach ", "foreach(", "while ", "while(", "switch ", "switch(", "catch ", "catch(", "return ", "return(", "new ", "throw ", "lock ", "lock(" };
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Exclude C# call expressions from method symbol extraction

This branch marks almost any parenthesized C# line as a .method symbol, so ordinary calls like Console.WriteLine(...), LINQ calls, or constructor invocations inside method bodies are indexed as declarations. That will significantly inflate symbol lists and degrade outline/search accuracy on real C# files, even though no new declarations exist on those lines. Method extraction needs a declaration-specific guard instead of relying on ( plus a small control-keyword denylist.

Useful? React with 👍 / 👎.

Comment on lines +1002 to +1005
if (startsWith(line, "using ")) {
const symbol_copy = try a.dupe(u8, line);
errdefer a.free(symbol_copy);
try outline.symbols.append(a, .{
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Distinguish C# using directives from using statements

The parser treats any line beginning with using as an import and appends it to outline.imports, but C# also uses using for local resource-management statements (using var ... / using (...)). Those common in-method statements will be recorded as dependencies, which corrupts import/dependency data and downstream getImportedBy results for C# files.

Useful? React with 👍 / 👎.

sanderdewijs added a commit to sanderdewijs/codedb that referenced this pull request Apr 2, 2026
Cherry-picked from justrach/codedb PR justrach#106 (unliftedq).
Adds parseCSharpLine with support for using directives, namespaces,
classes, interfaces, structs, enums, delegates, constants, and methods.
Includes stripCSharpModifiers and lastIdent helpers.

Co-Authored-By: unliftedq <unliftedq@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@justrach
Copy link
Copy Markdown
Owner

justrach commented Apr 2, 2026

Hey @unliftedq, thanks for adding C# support — the parser itself looks solid (using directives, namespaces, classes, interfaces, structs, enums, delegates, methods, constants with modifier stripping). Appreciate the contribution!

One issue though — the PR includes ~262 lines of whitespace reformatting on existing methods (indexFileInner, getContent, cloneOutline, getTree, getImportedBy, getHotFiles, rebuildDepsFor). Per our CONTRIBUTING.md:

Do not mix unrelated file churn into bug-fix or perf PRs

This reformatting creates massive merge conflicts with every other open PR (we just merged PHP support in #87 and are about to merge HCL in #109), and makes it very hard to review the actual C# changes.

Could you resubmit with only the C# parser additions? Specifically just:

  • csharp added to the Language enum
  • .cs detection in detectLanguage
  • The parseCSharpLine function and its helpers (stripCSharpModifiers, lastIdent)
  • The dispatch line in indexFileInner
  • The C# tests in tests.zig
  • isCommentOrBlank update for csharp (if applicable)

No reformatting of existing code — keep the original indentation as-is. That way it'll rebase cleanly and we can get it merged quickly.

Thanks again for the work!

@unliftedq unliftedq force-pushed the add-csharp-support branch from 590d12d to 4aaa6f0 Compare April 3, 2026 02:49
@unliftedq
Copy link
Copy Markdown
Contributor Author

Hey @unliftedq, thanks for adding C# support — the parser itself looks solid (using directives, namespaces, classes, interfaces, structs, enums, delegates, methods, constants with modifier stripping). Appreciate the contribution!

One issue though — the PR includes ~262 lines of whitespace reformatting on existing methods (indexFileInner, getContent, cloneOutline, getTree, getImportedBy, getHotFiles, rebuildDepsFor). Per our CONTRIBUTING.md:

Do not mix unrelated file churn into bug-fix or perf PRs

This reformatting creates massive merge conflicts with every other open PR (we just merged PHP support in #87 and are about to merge HCL in #109), and makes it very hard to review the actual C# changes.

Could you resubmit with only the C# parser additions? Specifically just:

  • csharp added to the Language enum
  • .cs detection in detectLanguage
  • The parseCSharpLine function and its helpers (stripCSharpModifiers, lastIdent)
  • The dispatch line in indexFileInner
  • The C# tests in tests.zig
  • isCommentOrBlank update for csharp (if applicable)

No reformatting of existing code — keep the original indentation as-is. That way it'll rebase cleanly and we can get it merged quickly.

Thanks again for the work!

It should be fixed now, previous unrelated change is unexpectedly introduced by the zig language server of my local zig extension.

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.

2 participants