Skip to content
This repository has been archived by the owner on Sep 30, 2024. It is now read-only.

Resolve syntactic symbol at request range #63189

Merged
merged 11 commits into from
Jun 12, 2024

Conversation

kritzcreek
Copy link
Contributor

@kritzcreek kritzcreek commented Jun 10, 2024

Closes https://linear.app/sourcegraph/issue/GRAPH-666/resolve-syntactic-symbol-at-the-range-specified-in-the-usages-request

Because the new occurrences API allows passing both a symbol or a range we need to be able to retrieve the syntactic symbol at the given range.

I added some utilty functions to the shared.Range and shared.Position types, which I assume are the position-ish types we want to use to communicate between resolver and codenav service code.

I left a few NOTE and TODO's that I'd like to discuss during review.

Test plan

I added both unit as well as property based tests for the utility functions on position and range.

In order to test the service functions I'd need to mock a bunch of systems, and I'm not sure if the test would have any meaning at that point (the logic is basically a single iteration and overlap check). If you'd like me to add it anyways let me know.

@kritzcreek kritzcreek requested a review from a team June 10, 2024 14:38
@cla-bot cla-bot bot added the cla-signed label Jun 10, 2024
@github-actions github-actions bot added team/graph Graph Team (previously Code Intel/Language Tools/Language Platform) team/product-platform labels Jun 10, 2024
@varungandhi-src
Copy link
Contributor

I've moved the utility functions to the SCIP repo. sourcegraph/scip#248

Rationale for the change:

  • Those types already exist, converting them to the Sourcegraph specific types here isn't giving us anything. If we want to keep shared.Range as-is for now, I recommend implementing the code in terms of scip.Range and then replacing the usages of shared.Range with scip.Range.
  • It seems at least some of the logic in this PR is predicated on the assumption that the Sourcegraph-specific types represent closed intervals (unless I'm misreading the code), which is not correct, at least when we're converting from the scip.Range type. Having fewer Range types overall reduces the risk of confusion.

@kritzcreek kritzcreek force-pushed the christoph/resolve-syntactic-symbol-at-request-range branch 2 times, most recently from 9026896 to f04d3b9 Compare June 11, 2024 10:25
Copy link
Contributor

@varungandhi-src varungandhi-src left a comment

Choose a reason for hiding this comment

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

Left some initial comments, key one is changing the signature of the getSyntacticSymbolsAtRange function.

internal/codeintel/codenav/service.go Outdated Show resolved Hide resolved
internal/codeintel/codenav/service.go Outdated Show resolved Hide resolved
internal/codeintel/codenav/service.go Show resolved Hide resolved
internal/codeintel/codenav/service.go Show resolved Hide resolved
Copy link
Contributor

@varungandhi-src varungandhi-src left a comment

Choose a reason for hiding this comment

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

Looks directionally OK, left some minor improvement suggestions.

internal/codeintel/codenav/service.go Outdated Show resolved Hide resolved
internal/codeintel/codenav/service.go Outdated Show resolved Hide resolved
internal/codeintel/codenav/service.go Outdated Show resolved Hide resolved
return nil, err
}

// TODO: Adjust symbolRange based on revision vs syntacticUpload.Commit
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this purely a matter of calling GitTreeTranslator.GetTargetCommitRangeFromSourceRange? If so, let's fix this right away instead of accruing a TODO.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

GitTreeTranslator is also a cache and has a relatively complicated API, might be a good candidate to look at during pairing.

@kritzcreek kritzcreek force-pushed the christoph/resolve-syntactic-symbol-at-request-range branch from d605278 to 7194c00 Compare June 12, 2024 16:24
@kritzcreek kritzcreek merged commit 3584351 into main Jun 12, 2024
14 checks passed
@kritzcreek kritzcreek deleted the christoph/resolve-syntactic-symbol-at-request-range branch June 12, 2024 16:37
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla-signed team/graph Graph Team (previously Code Intel/Language Tools/Language Platform) team/product-platform
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants