-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Sketch of SCIP-based GraphQL API #61217
Changes from 1 commit
e50bb3b
e5b9e38
df4fb88
203e505
1949594
eebbd29
072bbc0
8e947b7
4032028
2146fed
570798a
9269229
7c42739
e90ab20
5f0c62a
dbd4068
e0af435
653a197
e20c0a5
38fc951
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -105,6 +105,21 @@ type GitBlobLSIFData implements TreeEntryLSIFData { | |
""" | ||
character: Int! | ||
|
||
""" | ||
When specified, indicates that this request should be paginated and | ||
to fetch results starting at this cursor. | ||
A future request can be made for more results by passing in the | ||
'LocationConnection.pageInfo.endCursor' that is returned. | ||
""" | ||
after: String | ||
|
||
""" | ||
When specified, indicates that this request should be paginated and | ||
the first N results (relative to the cursor) should be returned. i.e. | ||
how many results to return per page. | ||
""" | ||
first: Int | ||
|
||
""" | ||
When specified, it filters references by filename. | ||
""" | ||
|
@@ -118,12 +133,12 @@ type GitBlobLSIFData implements TreeEntryLSIFData { | |
""" | ||
The line on which the symbol occurs (zero-based, inclusive). | ||
""" | ||
line: Int! | ||
line: Int | ||
|
||
""" | ||
The character (not byte) of the start line on which the symbol occurs (zero-based, inclusive). | ||
""" | ||
character: Int! | ||
character: Int | ||
Comment on lines
-121
to
+281
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. TODO: Revert these changes, we don't care about this API anymore |
||
|
||
""" | ||
When specified, indicates that this request should be paginated and | ||
|
@@ -231,6 +246,19 @@ type GitBlobLSIFData implements TreeEntryLSIFData { | |
character: Int! | ||
): Hover | ||
|
||
""" | ||
Either one of 'symbol' or 'range' must be provided, but this isn't enforced at the GraphQL | ||
layer due to the lack of support for input unions. | ||
https://github.com/graphql/graphql-wg/blob/main/rfcs/InputUnion.md | ||
""" | ||
usages( | ||
symbol: LookupSCIPSymbol, | ||
range: LookupRange, | ||
filter: UsagesFilter, | ||
first: Int, | ||
after: String, | ||
): UsageConnection! | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Anton's Q: Why not split this into RangeUsageConnection and SymbolUsageConnection? This will cause more complexity in the outputs because of input dependence. Varun's A: The output needs to have some complexity anyways because of needing to support search-based/syntactic/precise and some information will not be present depending on the data source. (Anton's idea: In GraphQL, you'd typically use union types for results so that caller can check the type and cast.) Also, depending on whether the symbol is file-local, repo-local or cross-repo, we do actually need different kinds of range information. |
||
|
||
""" | ||
Code diagnostics provided through LSIF. | ||
""" | ||
|
@@ -247,6 +275,77 @@ type GitBlobLSIFData implements TreeEntryLSIFData { | |
snapshot(indexID: ID!): [SnapshotData!] | ||
} | ||
|
||
""" | ||
In the future, we may want to extend this to allow passing in a suffix or a "symbol pattern". | ||
""" | ||
input LookupSCIPSymbol { | ||
name: String! | ||
provenance: Provenance! | ||
} | ||
|
||
type SCIPSymbol { | ||
name: String! | ||
provenance: Provenance! | ||
} | ||
varungandhi-src marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
input LookupRange { | ||
start: LookupPosition! | ||
end: LookupPosition! | ||
} | ||
|
||
input LookupPosition { | ||
line: Int! | ||
character: Int! | ||
} | ||
|
||
input UsagesFilter { | ||
and: [UsagesFilter!] | ||
or: [UsagesFilter!] | ||
not: UsagesFilter | ||
# TODO: Can we be flexible here and allow patterns while still maintaining fast queries. | ||
repository: String | ||
path: String | ||
varungandhi-src marked this conversation as resolved.
Show resolved
Hide resolved
|
||
kind: SymbolUsageKind | ||
# TODO: Provide a way of controlling fallback behavior for indexes? | ||
# Not super sure how that would work, given that for different repositories, | ||
# the hashes will all be different? | ||
} | ||
|
||
enum SymbolUsageKind { | ||
Definition, | ||
Reference, | ||
Implementation, | ||
Super, | ||
} | ||
|
||
type UsageConnection { | ||
nodes: [Usage!]! | ||
pageInfo: PageInfo! | ||
} | ||
|
||
type Usage { | ||
symbol: SCIPSymbol! | ||
""" | ||
NOTE: Do not pass | ||
TODO: For this blob, it is generally more useful to get +N/-N lines | ||
rather than having to pass a range internally for the contents since | ||
the offsets from the start will not be known a-priori. | ||
""" | ||
blob: GitBlob! | ||
varungandhi-src marked this conversation as resolved.
Show resolved
Hide resolved
|
||
""" | ||
Instead of blob { content }, allows accessing a sub-span of the content | ||
using relative coordinates from the range of this usage. If linesBefore | ||
or linesAfter is negative or exceeds the number of available lines, | ||
the value is interpreted as until the start/end of the file. | ||
""" | ||
surroundingBlobContent(surroundingLines: SurroundingLines = {linesBefore: 0, linesAfter: 0}): String! | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here, |
||
} | ||
|
||
input SurroundingLines { | ||
linesBefore: Int | ||
linesAfter: Int | ||
} | ||
|
||
""" | ||
The SCIP snapshot decoration for a single SCIP Occurrence. | ||
""" | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6172,17 +6172,55 @@ type HighlightedFile { | |
""" | ||
html: String! | ||
""" | ||
Base64 encoded JSON payload of LSIF Typed with syntax highlighting data. | ||
DEPRECATED: Base64 encoded JSON payload of SCIP with syntax highlighting data. | ||
varungandhi-src marked this conversation as resolved.
Show resolved
Hide resolved
|
||
""" | ||
lsif: String! | ||
""" | ||
""" | ||
document: AssociatedSCIPDocument! | ||
""" | ||
A list of the desired line ranges. Each list is a list of lines, where each element is an HTML | ||
table row '<tr>...</tr>' string. This is useful if you only need to display specific subsets of | ||
the file. | ||
""" | ||
lineRanges(ranges: [HighlightLineRange!]!): [[String!]!]! | ||
} | ||
|
||
enum Provenance { | ||
varungandhi-src marked this conversation as resolved.
Show resolved
Hide resolved
|
||
Precise, | ||
Syntactic, | ||
SearchBased, | ||
} | ||
|
||
interface WithProvenance { | ||
""" | ||
Coarse-grained information about the data source. | ||
""" | ||
provenance: Provenance! | ||
""" | ||
Opaque fine-grained information describing the data source. | ||
|
||
Provided only for debugging. | ||
|
||
This field should be ignored when checking structural equality. | ||
""" | ||
dataSource: String! | ||
varungandhi-src marked this conversation as resolved.
Show resolved
Hide resolved
|
||
} | ||
|
||
type AssociatedSCIPDocument implements WithProvenance { | ||
varungandhi-src marked this conversation as resolved.
Show resolved
Hide resolved
|
||
""" | ||
Base64 encoded SCIP payload. | ||
|
||
After decoding, the resulting byte buffer can be parsed with | ||
pre-generated bindings in the sourcegraph/scip repository or | ||
manually generating bindings using | ||
https://github.com/sourcegraph/scip/blob/main/scip.proto | ||
""" | ||
data: String! | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder: would it be more natural to use proto's canonical JSON encoding for a GraphQL API? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess the downside is then there is temptation to not use the SCIP bindings and just use the deserialized JSON object directly. Also it doesn't look like the bindings support JSON serialization. So nevermind, ignore me. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Some of the important Document data is already exposed by the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, makes sense. Thanks! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. By shoving this into a string field, you lose the ability to do a subselect, which kind of defeats GraphQL. That said, if we really need a proto representation here, I don't think that is blocking. However, from an APIs perspective, it feels a little cleaner to return JSON. If having to support streaming decoding here, I think I have another concern: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The thing here is that we want clients to use the SCIP proto-bindings for interacting with this field |
||
provenance: Provenance! | ||
dataSource: String! | ||
} | ||
|
||
""" | ||
A file match. | ||
""" | ||
|
Uh oh!
There was an error while loading. Please reload this page.