Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -44,6 +44,7 @@ tree-sitter-c-sharp = { version = "0.23.1" }
tree-sitter-html = "0.23.2"
tree-sitter-md = "0.3.2"
tree-sitter-yaml = "0.6.1"
tree-sitter-solidity = "=1.2.10"
ast-grep-core = "0.36.1"
ast-grep-language = "0.36.1"
clap = { version = "4.3", features = ["derive"] }
Expand Down
3 changes: 2 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -143,7 +143,7 @@ npx -y @probelabs/probe@latest agent "Refactor the login function" --allow-edit
- **Smart Ranking**: BM25, TF-IDF, and hybrid algorithms with optional BERT reranking
- **Token-Aware**: `--max-tokens` budget, session-based dedup to avoid repeating context
- **Built-in Agent**: Multi-provider (Anthropic, OpenAI, Google, Bedrock) with retry, fallback, and context compaction
- **Multi-Language**: Rust, Python, JavaScript, TypeScript, Go, C/C++, Java, Ruby, PHP, Swift, C#, and more
- **Multi-Language**: Rust, Python, JavaScript, TypeScript, Go, C/C++, Java, Ruby, PHP, Swift, Solidity, C#, and more

---

Expand Down Expand Up @@ -468,6 +468,7 @@ cargo install --path .
| Ruby | `.rb` |
| PHP | `.php` |
| Swift | `.swift` |
| Solidity | `.sol` |
| C# | `.cs` |
| Markdown | `.md` |

Expand Down
3 changes: 2 additions & 1 deletion docs/probe-cli/extraction-reference.md
Original file line number Diff line number Diff line change
Expand Up @@ -177,6 +177,7 @@ Probe supports extraction for many other languages including:
- **Ruby**: Methods, classes, modules, blocks
- **PHP**: Functions, classes, namespaces, attributes
- **Swift**: Functions, classes, structs, protocols, extensions
- **Solidity**: Contracts, interfaces, libraries, functions, modifiers, events, errors
- **C#**: Methods, classes, interfaces, namespaces, attributes
- **Markdown**: Sections, code blocks, lists, tables, frontmatter

Expand Down Expand Up @@ -433,4 +434,4 @@ probe extract src/api.js:27 --context 10
- **INTELLIGENT FALLBACKS**: Gracefully handles cases where AST parsing isn't possible

For more information on how Probe works internally, see [How Probe Works](how-it-works.md).
For details on search capabilities, see [Search Functionality](search-functionality.md).
For details on search capabilities, see [Search Functionality](search-functionality.md).
1 change: 1 addition & 0 deletions docs/probe-cli/query.md
Original file line number Diff line number Diff line change
Expand Up @@ -138,6 +138,7 @@ Required for accurate parsing:
| Ruby | `ruby`, `rb` | .rb |
| PHP | `php` | .php |
| Swift | `swift` | .swift |
| Solidity | `solidity`, `sol` | .sol |
| C# | `csharp`, `cs` | .cs |

```bash
Expand Down
2 changes: 1 addition & 1 deletion docs/probe-cli/search.md
Original file line number Diff line number Diff line change
Expand Up @@ -208,7 +208,7 @@ probe search "api" ./ --reranker ms-marco-tinybert --question "How is the REST A
| `-l`, `--language` | String | auto | Limit to programming language |

**Supported Languages:**
`rust`, `javascript`, `typescript`, `python`, `go`, `c`, `cpp`, `java`, `ruby`, `php`, `swift`, `csharp`, `yaml`, `html`, `markdown`
`rust`, `javascript`, `typescript`, `python`, `go`, `c`, `cpp`, `java`, `ruby`, `php`, `swift`, `solidity`, `csharp`, `yaml`, `html`, `markdown`

```bash
# Search only Python files
Expand Down
2 changes: 1 addition & 1 deletion docs/reference/adding-languages.md
Original file line number Diff line number Diff line change
Expand Up @@ -95,7 +95,7 @@ Add to language completion lists (2 locations):
### File 10: `npm/src/mcp/index.ts`
Add to supported languages description:
```rust
'Supported languages: rust, javascript, typescript, python, go, c, cpp, java, ruby, php, swift, csharp, yourlang.',
'Supported languages: rust, javascript, typescript, python, go, c, cpp, java, ruby, php, swift, solidity, csharp, yourlang.',
```

## Step 4: Documentation
Expand Down
3 changes: 1 addition & 2 deletions docs/reference/architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -104,7 +104,7 @@ pub trait LanguageImpl {
}
```

**Supported:** Rust, JavaScript, TypeScript, Python, Go, C, C++, Java, Ruby, PHP, Swift, C#, HTML, Markdown, YAML
**Supported:** Rust, JavaScript, TypeScript, Python, Go, C, C++, Java, Ruby, PHP, Swift, Solidity, C#, HTML, Markdown, YAML

### Performance Optimizations

Expand Down Expand Up @@ -418,4 +418,3 @@ agent.events.on('toolCall', (event) => {
- [API Reference](../probe-agent/sdk/api-reference.md) - SDK API
- [MCP Protocol](../probe-agent/protocols/mcp.md) - MCP integration
- [Performance](../probe-cli/performance.md) - Optimization guide

2 changes: 1 addition & 1 deletion docs/reference/faq.md
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,7 @@ Yes, Probe is open source under the Apache 2.0 license.

### What languages does Probe support?

Probe supports 15+ languages including Rust, JavaScript, TypeScript, Python, Go, C, C++, Java, Ruby, PHP, Swift, C#, HTML, Markdown, and YAML. See [Supported Languages](../supported-languages.md).
Probe supports 15+ languages including Rust, JavaScript, TypeScript, Python, Go, C, C++, Java, Ruby, PHP, Swift, Solidity, C#, HTML, Markdown, and YAML. See [Supported Languages](../supported-languages.md).

---

Expand Down
3 changes: 2 additions & 1 deletion docs/reference/language-support.md
Original file line number Diff line number Diff line change
Expand Up @@ -107,6 +107,7 @@ Probe currently supports a wide range of programming languages, including:
- Ruby
- PHP
- Swift
- Solidity
- C#
- Markdown

Expand Down Expand Up @@ -165,4 +166,4 @@ Tree-sitter provides several advantages for Probe:
- [Supported Languages](/supported-languages): Detailed information about each supported language
- [Adding New Languages](/adding-languages): Guide for adding support for new languages
- [Search Functionality](/search-functionality): How to use Probe's search features
- [Code Extraction](/code-extraction): Details on how Probe extracts code blocks
- [Code Extraction](/code-extraction): Details on how Probe extracts code blocks
11 changes: 10 additions & 1 deletion docs/reference/supported-languages.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,7 @@ Probe provides language-aware code search and extraction for a wide range of pro
| Ruby | `.rb` | ✅ | ✅ |
| PHP | `.php` | ✅ | ✅ |
| Swift | `.swift` | ✅ | ✅ |
| Solidity | `.sol` | ✅ | ✅ |
| C# | `.cs` | ✅ | ✅ |
| Markdown | `.md`, `.markdown` | ✅ | ✅ |
| YAML | `.yaml`, `.yml` | ✅ | ✅ |
Expand Down Expand Up @@ -128,6 +129,14 @@ Go also implements special handling for nested struct types.
- **Attribute Handling**: Properly handles C# attributes
- **Test Detection**: Identifies test classes and methods using NUnit, MSTest, or xUnit conventions

### Solidity

- **Contract Extraction**: Extracts contracts, interfaces, and libraries
- **Function Extraction**: Extracts functions, constructors, fallback/receive functions, and modifiers
- **Type Extraction**: Extracts structs, enums, user-defined value types, events, and custom errors
- **Comment Handling**: Associates NatSpec and regular comments with Solidity code blocks
- **Test Detection**: Identifies Foundry-style `.t.sol` files, `*Test.sol` contracts, `setUp`, `test*`, and `invariant_*` functions

### Markdown

- **Section Extraction**: Extracts complete sections based on headings
Expand Down Expand Up @@ -212,4 +221,4 @@ func ($RECEIVER $TYPE) $NAME($$$PARAMS) $$$BODY

## Adding Support for New Languages

If you're interested in adding support for a language that's not currently supported, see the [Adding New Languages](/adding-languages) page for a detailed guide.
If you're interested in adding support for a language that's not currently supported, see the [Adding New Languages](/adding-languages) page for a detailed guide.
1 change: 1 addition & 0 deletions lsp-daemon/Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -81,6 +81,7 @@ tree-sitter-c-sharp = "0.23.1"
tree-sitter-ruby = "0.23.1"
tree-sitter-swift = "0.7.0"
tree-sitter-php = "0.23.11"
tree-sitter-solidity = "=1.2.10"

[target.'cfg(unix)'.dependencies]
libc = "0.2"
Expand Down
2 changes: 2 additions & 0 deletions lsp-daemon/src/analyzer/tree_sitter_analyzer.rs
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,7 @@
"php" => Some("php"),
"swift" => Some("swift"),
"cs" => Some("csharp"),
"sol" => Some("solidity"),
_ => None,
}
}
Expand All @@ -56,7 +57,7 @@
extension_to_language_name(language_or_extension).unwrap_or(language_or_extension);

let language_parsers = self
.parsers

Check warning on line 60 in lsp-daemon/src/analyzer/tree_sitter_analyzer.rs

View check run for this annotation

probelabs / Visor: performance

performance Issue

Repeated heap allocation in hot path: `language_name.to_string()` is called on every parser get/return operation. This allocation occurs in ParserPool::get_parser and ParserPool::return_parser for HashMap entry operations, which are frequently called during parsing operations.
Raw output
Use `&str` keys in the HashMap instead of `String` to avoid allocations. Change `parsers: HashMap<String, Vec<tree_sitter::Parser>>` to `parsers: HashMap<&'static str, Vec<tree_sitter::Parser>>` and use static string literals for language names.
.entry(language_name.to_string())
.or_insert_with(Vec::new);

Expand Down Expand Up @@ -98,6 +99,7 @@
"java" => Some(tree_sitter_java::LANGUAGE),
"c" => Some(tree_sitter_c::LANGUAGE),
"cpp" | "c++" | "cxx" => Some(tree_sitter_cpp::LANGUAGE),
"solidity" | "sol" => Some(tree_sitter_solidity::LANGUAGE),
_ => None,
};

Expand Down
6 changes: 6 additions & 0 deletions lsp-daemon/src/daemon.rs
Original file line number Diff line number Diff line change
Expand Up @@ -7214,9 +7214,15 @@
"cpp" | "cc" | "cxx" | "hpp" => {
parser
.set_language(&tree_sitter_cpp::LANGUAGE.into())
.ok()?;

Check warning on line 7217 in lsp-daemon/src/daemon.rs

View check run for this annotation

probelabs / Visor: performance

performance Issue

Missing Solidity parser in daemon: The daemon's parser initialization doesn't include tree-sitter-solidity, which will cause symbol-at-position requests to fail for Solidity files.
Raw output
Add a match arm for `"sol" => { parser.set_language(&tree_sitter_solidity::LANGUAGE.into()).ok()?; Some(()) }` in the daemon's parser initialization.
Some(())
}
"sol" => {
parser
.set_language(&tree_sitter_solidity::LANGUAGE.into())
.ok()?;
Some(())
}
_ => None,
}?;

Expand Down
18 changes: 17 additions & 1 deletion lsp-daemon/src/fqn.rs
Original file line number Diff line number Diff line change
Expand Up @@ -41,9 +41,10 @@
"js" | "jsx" => Some(tree_sitter_javascript::LANGUAGE),
"ts" | "tsx" => Some(tree_sitter_typescript::LANGUAGE_TYPESCRIPT),
"java" => Some(tree_sitter_java::LANGUAGE),
"go" => Some(tree_sitter_go::LANGUAGE),

Check warning on line 44 in lsp-daemon/src/fqn.rs

View check run for this annotation

probelabs / Visor: performance

performance Issue

Missing Solidity parser in FQN generation: The `get_fqn_from_ast_with_content` function doesn't include tree-sitter-solidity in the language mapping, which will cause FQN generation to fail for Solidity files.
Raw output
Add `"sol" => Some(tree_sitter_solidity::LANGUAGE)` to the language match statement in `get_fqn_from_ast_with_content`.
"c" => Some(tree_sitter_c::LANGUAGE),
"cpp" | "cc" | "cxx" => Some(tree_sitter_cpp::LANGUAGE),
"sol" => Some(tree_sitter_solidity::LANGUAGE),
_ => None,
};

Expand Down Expand Up @@ -357,10 +358,10 @@
}

/// Get language-specific separator for FQN components
fn get_language_separator(extension: &str) -> &str {

Check warning on line 361 in lsp-daemon/src/fqn.rs

View check run for this annotation

probelabs / Visor: architecture

architecture Issue

Solidity language handling is scattered across multiple functions: get_language_separator() adds 'sol' (line 364), is_method_node() adds 4 Solidity node kinds (lines 382-389), is_namespace_node() adds 5 Solidity node kinds (lines 411-418). This scatter-gun approach requires updating multiple locations for any Solidity changes, violating DRY and increasing maintenance burden compared to centralized language-specific modules.
Raw output
Consider centralizing Solidity-specific logic in a dedicated module or trait implementation that these utility functions can delegate to, similar to how other languages have specialized analyzers.

Check warning on line 361 in lsp-daemon/src/fqn.rs

View check run for this annotation

probelabs / Visor: performance

performance Issue

Inefficient match statement for language separator: The match statement uses string comparisons for every call to `get_language_separator`. This function is called frequently during FQN generation, and the string matching is inefficient.
Raw output
Use a static HashMap<&'static str, &'static str> for O(1) lookup instead of linear string matching in the match statement.
match extension {
"rs" | "cpp" | "cc" | "cxx" | "hpp" | "hxx" | "rb" => "::",
"py" | "js" | "ts" | "jsx" | "tsx" | "java" | "go" | "cs" => ".",
"py" | "js" | "ts" | "jsx" | "tsx" | "java" | "go" | "cs" | "sol" => ".",
"php" => "\\",
_ => "::", // Default to Rust-style for unknown languages
}
Expand All @@ -381,6 +382,13 @@
"java" | "cs" => kind == "method_declaration",
"go" => kind == "function_declaration",
"cpp" | "cc" | "cxx" => matches!(kind, "function_definition" | "method_declaration"),
"sol" => matches!(
kind,
"function_definition"
| "constructor_definition"
| "modifier_definition"
| "fallback_receive_definition"
),
_ => kind.contains("function") || kind.contains("method"),
}
}
Expand All @@ -403,6 +411,14 @@
kind,
"class_specifier" | "struct_specifier" | "namespace_definition"
),
"sol" => matches!(
kind,
"contract_declaration"
| "interface_declaration"
| "library_declaration"
| "struct_declaration"
| "enum_declaration"
),
_ => {
// Fallback for unknown languages: try to detect common node types
kind.contains("class") || kind.contains("struct") || kind.contains("namespace")
Expand Down
29 changes: 28 additions & 1 deletion lsp-daemon/src/indexing/ast_extractor.rs
Original file line number Diff line number Diff line change
Expand Up @@ -697,6 +697,9 @@
crate::language_detector::Language::Java => Ok(tree_sitter_java::LANGUAGE.into()),
crate::language_detector::Language::C => Ok(tree_sitter_c::LANGUAGE.into()),
crate::language_detector::Language::Cpp => Ok(tree_sitter_cpp::LANGUAGE.into()),
crate::language_detector::Language::Solidity => {
Ok(tree_sitter_solidity::LANGUAGE.into())
}
_ => Err(anyhow::anyhow!("Unsupported language: {:?}", language)),
}
}
Expand Down Expand Up @@ -831,9 +834,23 @@
"method_declaration" | "constructor_declaration" => (SymbolKind::Function, true),
"class_declaration" => (SymbolKind::Class, true),
"interface_declaration" => (SymbolKind::Interface, true),
"field_declaration" => (SymbolKind::Variable, true),

Check warning on line 837 in lsp-daemon/src/indexing/ast_extractor.rs

View check run for this annotation

probelabs / Visor: architecture

architecture Issue

The Solidity symbol mapping is added inline within the existing match statement (lines 837-850) rather than as a separate match arm. While this works functionally, it creates an inconsistent pattern where Solidity is embedded in the existing structure rather than being a first-class case like Rust, Python, Go, Java, and C++ which have clear separate match arms.
Raw output
Refactor to add Solidity as a separate match arm: crate::language_detector::Language::Solidity => match node_kind { ... }, following the established pattern for other languages.

Check warning on line 837 in lsp-daemon/src/indexing/ast_extractor.rs

View check run for this annotation

probelabs / Visor: performance

performance Issue

Inefficient nested match statements for node kind mapping: The Solidity language mapping uses nested match statements that check `node_kind` multiple times. This pattern is duplicated across multiple language implementations and creates unnecessary branching.
Raw output
Use a single match with consolidated patterns or a static HashMap for O(1) node kind to symbol kind lookup. This would be more efficient than nested match statements.
_ => (SymbolKind::Function, false),
},
crate::language_detector::Language::Solidity => match node_kind {
"function_definition" | "fallback_receive_definition" => {
(SymbolKind::Function, true)
}
"constructor_definition" | "modifier_definition" => (SymbolKind::Method, true),
"contract_declaration" | "library_declaration" => (SymbolKind::Class, true),
"interface_declaration" => (SymbolKind::Interface, true),
"struct_declaration" => (SymbolKind::Struct, true),
"enum_declaration" => (SymbolKind::Enum, true),
"event_definition" | "error_declaration" => (SymbolKind::Type, true),
"state_variable_declaration" => (SymbolKind::Variable, true),
"user_defined_type_definition" => (SymbolKind::Type, true),
_ => (SymbolKind::Function, false),
},
_ => {
// For other languages, try some common patterns
match node_kind {
Expand Down Expand Up @@ -930,10 +947,20 @@
}
}
_ => continue,
}

Check warning on line 950 in lsp-daemon/src/indexing/ast_extractor.rs

View check run for this annotation

probelabs / Visor: architecture

architecture Issue

The get_symbol_name() method adds Solidity-specific handling for constructor_definition and fallback_receive_definition (lines 950-962) directly in a generic utility method. This violates single responsibility - the method now handles both generic symbol name extraction and Solidity-specific node name resolution. The method should delegate to language-specific implementations.
Raw output
Move Solidity-specific node name handling to a language-specific helper or trait method, then call it conditionally only for Solidity language from the generic get_symbol_name() method.

Check warning on line 950 in lsp-daemon/src/indexing/ast_extractor.rs

View check run for this annotation

probelabs / Visor: performance

performance Issue

Inefficient string parsing for special function detection: The code calls `node.utf8_text(content)` followed by `text.trim_start().starts_with("receive")` which creates temporary strings and performs multiple string operations. This is inefficient for hot path symbol extraction.
Raw output
Use byte-level comparison directly on the content slice to avoid UTF-8 validation and string allocation. Check if the bytes start with b"receive" after skipping whitespace bytes.
}

None
match node.kind() {
"constructor_definition" => Some("constructor".to_string()),
"fallback_receive_definition" => node.utf8_text(content).ok().map(|text| {
if text.trim_start().starts_with("receive") {
"receive".to_string()
} else {
"fallback".to_string()
}
}),
_ => None,
}
}
}

Expand Down
8 changes: 8 additions & 0 deletions lsp-daemon/src/indexing/config.rs
Original file line number Diff line number Diff line change
Expand Up @@ -1401,6 +1401,7 @@
Language::Java,
Language::C,
Language::Cpp,
Language::Solidity,

Check warning on line 1404 in lsp-daemon/src/indexing/config.rs

View check run for this annotation

probelabs / Visor: performance

performance Issue

Missing Solidity in language configuration loading: The `load_language_configs_from_env` function doesn't include `Language::Solidity` in the list of languages to load configurations for. This means Solidity-specific indexing features cannot be configured via environment variables.
Raw output
Add `Language::Solidity` to the array of languages in `load_language_configs_from_env` and add a match arm to configure Solidity-specific features like extract_contracts, extract_events, and extract_modifiers.
] {
let lang_str = format!("{language:?}").to_uppercase();
let mut config = LanguageIndexConfig::default();
Expand Down Expand Up @@ -1498,6 +1499,11 @@
features.set_language_feature("extract_namespaces".to_string(), true);
features.set_language_feature("extract_classes".to_string(), true);
}
Language::Solidity => {

Check notice on line 1502 in lsp-daemon/src/indexing/config.rs

View check run for this annotation

probelabs / Visor: architecture

architecture Issue

Solidity feature flags (extract_contracts, extract_events, extract_modifiers) are added at lines 1502-1507 but are not integrated with the actual symbol extraction logic in ast_extractor.rs. The extraction happens unconditionally based on node kinds regardless of these flags, creating a disconnect between configuration and implementation.
Raw output
Either implement feature flag checking in ast_extractor.rs or remove these unused flags. Following the Rust pattern (extract_macros, extract_traits), these flags should control whether specific symbol types are extracted.
features.set_language_feature("extract_contracts".to_string(), true);
features.set_language_feature("extract_events".to_string(), true);
features.set_language_feature("extract_modifiers".to_string(), true);
}
_ => {}
}

Expand All @@ -1518,7 +1524,7 @@
fn parse_bool_env(value: &str, var_name: &str) -> Result<bool> {
match value.to_lowercase().as_str() {
"true" | "1" | "yes" | "on" | "enabled" => Ok(true),
"false" | "0" | "no" | "off" | "disabled" => Ok(false),

Check warning on line 1527 in lsp-daemon/src/indexing/config.rs

View check run for this annotation

probelabs / Visor: performance

performance Issue

Missing Solidity in default extensions mapping: The `default_extensions_for_language` function doesn't include a match arm for `Language::Solidity`, which will cause it to return an empty vector for Solidity file extensions.
Raw output
Add a match arm for `Language::Solidity => vec!["sol".to_string()]` in the `default_extensions_for_language` function.
_ => Err(anyhow!("Invalid boolean value for {}: {} (use true/false, 1/0, yes/no, on/off, enabled/disabled)", var_name, value)),
}
}
Expand All @@ -1540,6 +1546,7 @@
"hpp".to_string(),
"hxx".to_string(),
],
Language::Solidity => vec!["sol".to_string()],
_ => vec![],
}
}
Expand All @@ -1557,6 +1564,7 @@
"java" => Ok(Language::Java),
"c" => Ok(Language::C),
"cpp" | "c++" => Ok(Language::Cpp),
"solidity" | "sol" => Ok(Language::Solidity),
_ => Err(anyhow!("Unknown language: {}", s)),
}
}
Expand Down
7 changes: 4 additions & 3 deletions lsp-daemon/src/indexing/file_detector.rs
Original file line number Diff line number Diff line change
Expand Up @@ -122,6 +122,7 @@ impl Default for DetectionConfig {
"rb",
"php",
"swift",
"sol",
"cs",
"kt",
"scala",
Expand Down Expand Up @@ -384,9 +385,9 @@ impl FileChangeDetector {
// Check if this extension is supported based on our known languages
let supported_languages = [
"rs", "js", "jsx", "ts", "tsx", "py", "go", "c", "h", "cpp", "cc", "cxx", "hpp",
"hxx", "java", "rb", "php", "swift", "cs", "kt", "scala", "clj", "ex", "exs",
"erl", "hrl", "hs", "lhs", "ml", "mli", "fs", "fsx", "fsi", "dart", "jl", "r", "R",
"m", "mm", "pl", "pm", "sh", "bash", "zsh", "fish", "lua", "vim", "sql",
"hxx", "java", "rb", "php", "swift", "sol", "cs", "kt", "scala", "clj", "ex",
"exs", "erl", "hrl", "hs", "lhs", "ml", "mli", "fs", "fsx", "fsi", "dart", "jl",
"r", "R", "m", "mm", "pl", "pm", "sh", "bash", "zsh", "fish", "lua", "vim", "sql",
];

if supported_languages.contains(&extension) {
Expand Down
6 changes: 6 additions & 0 deletions lsp-daemon/src/language_detector.rs
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,7 @@ pub enum Language {
Ruby,
Php,
Swift,
Solidity,
Kotlin,
Scala,
Haskell,
Expand All @@ -45,6 +46,7 @@ impl Language {
Language::Ruby => "ruby",
Language::Php => "php",
Language::Swift => "swift",
Language::Solidity => "solidity",
Language::Kotlin => "kotlin",
Language::Scala => "scala",
Language::Haskell => "haskell",
Expand Down Expand Up @@ -72,6 +74,7 @@ impl Language {
"ruby" => Some(Language::Ruby),
"php" => Some(Language::Php),
"swift" => Some(Language::Swift),
"solidity" | "sol" => Some(Language::Solidity),
"kotlin" => Some(Language::Kotlin),
"scala" => Some(Language::Scala),
"haskell" => Some(Language::Haskell),
Expand Down Expand Up @@ -146,6 +149,9 @@ impl LanguageDetector {
// Swift
extension_map.insert("swift".to_string(), Language::Swift);

// Solidity
extension_map.insert("sol".to_string(), Language::Solidity);

// Kotlin
extension_map.insert("kt".to_string(), Language::Kotlin);
extension_map.insert("kts".to_string(), Language::Kotlin);
Expand Down
Loading
Loading