Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Add SymbolRole for representing forward declarations #217

Merged
merged 5 commits into from
Nov 3, 2023

Conversation

varungandhi-src
Copy link
Contributor

@varungandhi-src varungandhi-src commented Nov 3, 2023

Adds a new SymbolRole for forward declarations so that certain occurrences can be marked
with this role for C-based languages, optionally allowing clients such as a web UI to filter out
or down-rank them.

Question:

  • There are similar constructs in other languages, most prominently type signatures in OCaml's .mli files. Should we change the name ForwardDeclaration to be something more generic else to account for that too? Should we add a separate SymbolRole for that? Deal with it later instead of right now? -- Renamed to ForwardDefinition.

Fixes #131

Related PR: https://github.com/sourcegraph/sourcegraph/pull/58082

Test plan

I've added an optional forward_decl field to reprolang along with a snapshot test for it.

scip.proto Outdated Show resolved Hide resolved
@varungandhi-src varungandhi-src changed the title feat: Add ForwardDeclaration SymbolRole feat: Add SymbolRole for representing forward declarations Nov 3, 2023
Copy link
Member

@olafurpg olafurpg left a comment

Choose a reason for hiding this comment

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

LGTM 👍🏻 One non-blocking comment

@@ -0,0 +1,8 @@
reference forward_definition abc#
Copy link
Member

Choose a reason for hiding this comment

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

nit: I would expect the repro syntax to work like this

Suggested change
reference forward_definition abc#
forward_definition abc#

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I put it inside reference so that it's clearer that it is also a reference, not a tri-state of definition/reference/forward definition.

Copy link
Member

Choose a reason for hiding this comment

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

Should we update the docstring to emphasize that you should set Definition and ForwardDefinition? It might be easy to misunderstand that setting ForwardDefinition alone implies Definition

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, that would be incorrect. You should NOT set Definition if you set ForwardDefinition because a ForwardDefinition is actually a reference, it is not a Definition because it doesn't have a body.

I've added a lint for this in the scip lint command and mentioned the above requirement in the doc comment.

Copy link
Member

Choose a reason for hiding this comment

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

It is a definition IMO because it's a valid destination for "Go to definition". When I trigger "Go to implementation" then I would expect it to go to the non-forward definition.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If you still disagree, let's discuss it synchronously some time next week. It would be helpful for me to show some live examples of code nav behavior in C++.

Copy link
Member

Choose a reason for hiding this comment

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

I trust your call on this. It might be worth renaming from ForwardDefinition if this is not technically a definition in your opinion.

Copy link
Member

Choose a reason for hiding this comment

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

Or updating the docstring to emphasize that Definition should not be set

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ugh, I thought I updated the docstring earlier, but I must've stashed that change instead of merging it. 🤦🏽

Yes, I'll do that.

Copy link
Member

Choose a reason for hiding this comment

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

In my mental model, it is a definition with lower priority. If you have two ambiguous definitions and one has the ForwardDefinition role then we can discard it. I would rather use that application logic than requiring the client to treat a non-definition (which is confusingly named ForwardDefinition) as a definition

@mrnugget
Copy link
Contributor

mrnugget commented Nov 3, 2023

@olafurpg Can I merge? @varungandhi-src said he's going to be out rest of day and asked wehther I could merge this.

@olafurpg olafurpg merged commit 3935113 into main Nov 3, 2023
6 checks passed
@olafurpg olafurpg deleted the vg/forward-decl branch November 3, 2023 11:31
@olafurpg
Copy link
Member

olafurpg commented Nov 3, 2023

No problem merging, the comment was only minor

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.

Add a (forward) declaration role
3 participants