Crates.io | gossiphs |
lib.rs | gossiphs |
version | 0.8.3 |
source | src |
created_at | 2024-04-19 13:38:29.257594 |
updated_at | 2024-10-20 14:12:16.250597 |
description | A Rust lib for general code file relationship analysis. Based on tree-sitter and git analysis. |
homepage | |
repository | https://github.com/williamfzc/gossiphs |
max_upload_size | |
id | 1213697 |
size | 153,930 |
An experimental Rust library for general code file relationship analysis. Based on tree-sitter and git analysis.
Gossiphs can analyze the history of commits and the relationships between variable declarations and references in your codebase to obtain a relationship diagram of the code files.
It also allows developers to query the content declared in each file, thereby enabling free search for its references throughout the entire codebase to achieve more complex analysis.
graph TD
A[main.py] --- S1[func_main] --- B[module_a.py]
A --- S2[Handler] --- C[module_b.py]
B --- S3[func_util] --- D[utils.py]
C --- S3[func_util] --- D
A --- S4[func_init] --- E[module_c.py]
E --- S5[process] --- F[module_d.py]
E --- S6[Processor] --- H[module_e.py]
H --- S7[transform] --- I[module_f.py]
I --- S3[func_util] --- D
We are expanding language support based on Tree-Sitter Query, which isn't too costly. If you're interested, you can check out the contribution section.
Language | Status |
---|---|
Rust | ✅ |
Python | ✅ |
TypeScript | ✅ |
JavaScript | ✅ |
Golang | ✅ |
Java | ✅ |
Kotlin | ✅ |
Swift | ✅ |
You can see the rule files here.
You can find pre-compiled files for your platform
on Our Release Page. After extraction, you can use gossiphs --help
to find the corresponding help.
gossiphs relation
gossiphs relation --csv scores.csv --symbol-csv symbols.csv
And you can use something like pandas to handle this matrix and apply further analysis without accessing the rust part.
shows the relations between files by int score.
examples/mini.rs | src/extractor.rs | src/graph.rs | src/lib.rs | src/main.rs | src/rule.rs | src/server.rs | src/symbol.rs | |
---|---|---|---|---|---|---|---|---|
examples/mini.rs | ||||||||
src/extractor.rs | 8 | 1 | ||||||
src/graph.rs | 9 | 23 | 5 | |||||
src/lib.rs | ||||||||
src/main.rs | 5 | 1 | ||||||
src/rule.rs | 18 | |||||||
src/server.rs | 2 | |||||||
src/symbol.rs | 1 | 28 | 64 | 32 | 13 |
src/graph.rs
and src/symbol.rs
have been used by example/mini.rs
.src/rule.rs
has only been used by src/extractor.rs
.shows the relations between files by real reference names.
examples/mini.rs | src/extractor.rs | src/graph.rs | src/lib.rs | src/main.rs | src/rule.rs | src/server.rs | src/symbol.rs | |
---|---|---|---|---|---|---|---|---|
examples/mini.rs | ||||||||
src/extractor.rs | extract | extract | ||||||
src/graph.rs | file_metadata|default|related_files|related_symbols|files | related_files|files | file_metadata|files|empty|related_files | |||||
src/lib.rs | ||||||||
src/main.rs | default | main | ||||||
src/rule.rs | get_rule | |||||||
src/server.rs | server_main | |||||||
src/symbol.rs | from | new|id|new_ref|from|new_def | list_definitions|list_symbols|id|link_symbol_to_symbol|link_file_to_symbol|list_references_by_definition|enhance_symbol_to_symbol|get_symbol|from|new|add_symbol|add_file|list_references|pairs_between_files|list_definitions_by_reference | new|id|from|pairs_between_files | list_references_by_definition|new|from|list_definitions_by_reference|get_symbol|id |
file_metadata
/related_files
... from src/graph.rs
.# diff between HEAD and HEAD~1
gossiphs diff
# custom diff
gossiphs diff --target HEAD~5
gossiphs diff --target d18a5db39752d244664a23f74e174448b66b5b7e
# output json
gossiphs diff --json
output:
src/services/user-info/index.ts
├── src/background-script/driveUploader.ts (ADDED)
├── src/background-script/task.ts (DELETED)
├── scripts/download-config.js (DELETED)
├── src/background-script/sdk.ts
├── src/services/user-info/listener.ts
├── src/services/config/index.ts
├── src/content-script/modal.ts
├── src/background-script/help-center.ts
For example, you can use this command to generate an obsidian vault:
gossiphs obsidian --project-path . --vault-dir ./target_vault
and get a code relation graph:
Please refer to examples for usage.
fn main() {
let config = GraphConfig::default();
let g = Graph::from(config);
// done! just try it
let all_files = g.files();
for file in &all_files {
// related file search
let related_files = g.related_files(file);
for each_related in &related_files {
println!("{} -> {}: {}", file, each_related.name, each_related.score);
}
// file details
if !related_files.is_empty() {
let random_file = related_files[0].name.clone();
let meta = g.file_metadata(&random_file);
println!("symbols in {}: {:?}", random_file, meta.symbols.len());
// and query the symbol infos
}
}
}
Starting a local server similar to LSP for other clients to use may be a reasonable approach, which is what we are currently doing.
./gossiphs server --project-path ./your/project --strict
API desc can be found here.
Code navigation is a fascinating subject that plays a pivotal role in various domains, such as:
In the past, I endeavored to apply LSP/LSIF technologies and techniques like Github's Stack-Graphs to impact analysis, encountering different challenges along the way. For our needs, a method akin to Stack-Graphs aligns most closely with our expectations. However, the challenges are evident: it requires crafting highly language-specific rules, which is a considerable investment for us, given that we do not require such high precision data.
We attempt to make some trade-offs on the challenges currently faced by stack-graphs to achieve our expected goals to a certain extent:
Gossiphs constructs a graph that interconnects symbols of definitions and references.
Unlike stack-graphs, we have omitted the highly complex scope analysis and instead opted to refine our edges using commit histories. This approach significantly reduces the complexity of rule writing, as the rules only need to specify which types of symbols should be exported or imported for each file.
While there is undoubtedly a trade-off in precision, the benefits are clear:
Static analysis has its limits, such as dynamic binding. Therefore, it is unlikely to achieve the level of accuracy provided by LSP, but it can offer sufficient accuracy in the areas where it is primarily used.
The method we use to demonstrate accuracy is to compare the results with those of LSP/LSIF. It must be admitted that static inference is almost impossible to obtain all reference relationships like LSP, but in strict mode, our calculation accuracy is still quite considerable. In normal mode, you can decide whether to adopt the relationship based on the weight returned.
Repo | Precision (Strict Mode) | Graph Generated Time |
---|---|---|
https://github.com/williamfzc/srctx | 80/80 = 100 % | 83.139791ms |
https://github.com/gin-gonic/gin | 160/167 = 95.80838 % | 310.6805ms |
The project is still in a very early and experimental stage. If you are interested, please leave your thoughts through an issue. In the short term, we hope to build better support for more languages.
You just need to: