You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support Solidity by integrating solidity-parser-antlr #1754
Current indexing/parsing support does not cover Solidity files, so Solidity repositories can be skipped, partially indexed, or produce incomplete code graph/data. That makes the repository memory features much less useful for teams working with smart contracts.
Proposed solution
Add Solidity support by integrating solidity-parser-antlr into the parsing pipeline. Use it to parse Solidity source files, extract declarations/imports/references, and feed the resulting AST into indexing and search so Solidity projects are handled consistently with other supported languages. Include representative public OSS Solidity repos as test beds to validate coverage and parsing quality.
Alternatives considered
Alternative approaches could include extending a hand-rolled parser or relying on simpler regex-based extraction, but those would likely be less accurate and harder to maintain than using a dedicated Solidity parser.
Confirmations
I searched existing issues and this is not a duplicate.
Happy to pick this up — quick check before I start: solidity-parser-antlr looks unmaintained (last updates years old), while @solidity-parser/parser is the actively maintained fork with the same AST shape. OK if I implement against the fork instead? Wanted to confirm before starting so I don't build on a dead dependency.
Actually I'm working on it in one of my forks and I can do one pr adding solidity as a single lang, but it would take a couple of weeks for me to do so.
Meanwhile you can proceed with solidity-parser/parser
Opened a PR on the existing Tree-sitter Solidity path to address the missing modifier/decorator tracking.
This keeps the current C-based architecture and does not introduce a Node.js runtime.
The PR specifically adds modifier_invocation tracking so usages such as onlyOwner are included in the code graph.
I can also proceed with the @solidity-parser/parser integration discussed above if the broader scope of #1754 is preferred.
Thank you for separating Tree-sitter modifier tracking from the proposed parser integration. The broader dependency and contributor coordination need maintainer direction. Sorry for the delay; this is waiting on maintainer follow-up, and I’ll follow up soon.
Activity
sanskar717 commentedon Sep 3, 2026
Happy to pick this up — quick check before I start: solidity-parser-antlr looks unmaintained (last updates years old), while @solidity-parser/parser is the actively maintained fork with the same AST shape. OK if I implement against the fork instead? Wanted to confirm before starting so I don't build on a dead dependency.
djmahe4 commentedon Sep 7, 2026
Actually I'm working on it in one of my forks and I can do one pr adding solidity as a single lang, but it would take a couple of weeks for me to do so.
Meanwhile you can proceed with
solidity-parser/parsersanskar717 commentedon Sep 7, 2026
@DeusData @djmahe4
Opened a PR on the existing Tree-sitter Solidity path to address the missing modifier/decorator tracking.
This keeps the current C-based architecture and does not introduce a Node.js runtime.
The PR specifically adds
modifier_invocationtracking so usages such asonlyOwnerare included in the code graph.I can also proceed with the
@solidity-parser/parserintegration discussed above if the broader scope of #1754 is preferred.DeusData commentedon Oct 25, 2026
Thank you for separating Tree-sitter modifier tracking from the proposed parser integration. The broader dependency and contributor coordination need maintainer direction. Sorry for the delay; this is waiting on maintainer follow-up, and I’ll follow up soon.
sanskar717 commentedon Oct 26, 2026
Thanks, @DeusData, no rush at all. I'll wait for the maintainer direction.