Consider reducing redundancy between declaration and references
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- backend-api-design, tooling
Research direction
Start with the LSIF declaration, reference, definition, ResultSet, and item relationships described in issue #25. Determine whether declaration and definition edges can be removed without losing information across languages, then document the decision and any required specification changes; the payload names no files or tests.
Written by the indexing model from the issue text.
Description
Consider the following C++ code:
void foo(); // R1
void foo(); // R2
where R1 and R2 indicate two distinct Range vertices.
Following the current LSIF spec, the output should contain the following vertices:
- Range for R1
- Range for R2
- ResultSet
- DeclarationResult
- ReferenceResult
and the following edges:
a) 1 -> 3; refersTo
b) 2 -> 3; refersTo
c) 3 -> 4; textDocument/declaration
d) 3 -> 5; textDocument/references
e) 5 -> 1; item (property=declaration)
f) 5 -> 2; item (property=declaration)
g) 4 -> 1
h) 4 -> 2
Note that "e" and "f" could be implicit edges (inlined into array), and "g" and "h" in the current spec are implicit edges (formed by the result field array in DeclarationResult), but that does not affect the crux of the issues.
The crux is that "e" is redundant with "g", and "f" is redundant with "h", and such redundancy would be repeated for every additional declaration in the source code.
Similar redundancy would be present for DefinitionResult and item (property=definition), although on much smaller scale (in general, there is only one definition for a given ResultSet).
I propose that declaration and definition edges going out of ReferenceResult are dropped. They can easily be reconstructed for serving textDocument/references query by augmenting that result set with the results from textDocument/declaration and textDocument/definition from the same ResultSet. Note also that after dropping these edges, "property" field on the "item" edge will no longer be necessary, since "reference" and "referenceResult" could be distinguished by the type of the incoming vertex of the "item" edge.
Are there languages that would make the above not possible?
- Dominant language
- TypeScript
- Stars
- 198
- Forks
- 40
- Avg merge
- 3d 7h
- Merged PRs (30d)
- 1
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/lsif-node
-
feature-request
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
feature-request
Difficulty 3/5 1-2 days Newbie friendliness 35/100
-
InlayHint for LSIF Openfeature-request
Difficulty 5/5 Over a week Newbie friendliness 20/100
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
feature-request
Difficulty 4/5 3-5 days Newbie friendliness 30/100
All issues in microsoft/lsif-node
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
danielmiessler/LifeOS#2218 ·