search: expose parse tree via GQL [3/3]
Created by: rvantonder
Stacked on #11773.
This PR introduces the endpoint that exposes the query parse tree via GQL for web/query input applications. It's not ready yet the way I want it, but nevertheless returns the current parse tree data of a processed query. No tests: this is an experimental endpoint and the spec isn't fixed yet.
CC @lguychard @attfarhan: let me know if the choice of capitalization in the JSON output works for you (all fields lowercase, I debated making operator names capitalized, like AND
or OR
, but decided against it for consistency's sake).
expand for current example JSON format
query { parseSearchQuery( query: "repo:foo file:bar b.*z or qux", patternType: regexp ) }
[ { "and": [ { "field": "repo", "value": "foo", "negated": false, "range": { "start": { "line": 0, "column": 0 }, "end": { "line": 0, "column": 8 } } }, { "field": "file", "value": "bar", "negated": false, "range": { "start": { "line": 0, "column": 9 }, "end": { "line": 0, "column": 17 } } }, { "or": [ { "value": "b.*z", "negated": false, "labels": [ "HeuristicHoisted" ], "range": { "start": { "line": 0, "column": 18 }, "end": { "line": 0, "column": 23 } } }, { "value": "qux", "negated": false, "labels": [ "HeuristicHoisted", "HeuristicParensAsPatterns", "Literal" ], "range": { "start": { "line": 0, "column": 26 }, "end": { "line": 0, "column": 29 } } } ] } ] } ]
TODOs before it's 'ready for use', I need to update the following in the internals in separate PRs:
-
I remove the top-level list that encloses the query. This requires a deeper refactoring so that nodes are always rooted with an operator. The current convention allows a possibly flat list of parameters (i.e., multiple roots) for flat queries, and I'd like to change that convention.
-
I need to still describe a spec of the JSON for including (1) the parse tree of the processed/transformed query (which we might produce when simplifying the query) (2) the parse tree of the raw query, and the possibly (3) alternative suggestions for the query in ambiguous cases. The endpoint currently exposes only (1).
-
Improving labels for (regex operators, better labels).
Merge request reports
Activity
Created by: codecov[bot]
Codecov Report
Merging #11776 into rvt/record-ranges-for-literal-parser will decrease coverage by
0.17%
. The diff coverage is81.81%
.@@ Coverage Diff @@ ## rvt/record-ranges-for-literal-parser #11776 +/- ## ======================================================================== - Coverage 47.86% 47.69% -0.18% ======================================================================== Files 1402 1402 Lines 80032 79768 -264 Branches 6675 6686 +11 ======================================================================== - Hits 38309 38042 -267 - Misses 38138 38152 +14 + Partials 3585 3574 -11
Flag Coverage Δ #go 51.85% <81.81%> (-0.23%)
#storybook 10.11% <ø> (ø)
#typescript 36.61% <ø> (ø)
#unit 47.29% <81.81%> (-0.18%)
Impacted Files Coverage Δ cmd/frontend/graphqlbackend/search_results.go 42.41% <0.00%> (ø)
internal/search/query/mapper.go 92.30% <62.50%> (ø)
internal/search/query/literal_parser.go 88.94% <94.44%> (+0.38%)
internal/search/query/transformer.go 98.49% <100.00%> (ø)
enterprise/internal/codeintel/store/store.go 59.64% <0.00%> (-9.67%)
...terprise/internal/codeintel/store/observability.go 92.07% <0.00%> (-6.16%)
...ntel-bundle-manager/internal/janitor/db_records.go 52.45% <0.00%> (-4.84%)
...e-intel-bundle-manager/internal/janitor/janitor.go 4.16% <0.00%> (-3.25%)
enterprise/internal/codeintel/store/uploads.go 89.89% <0.00%> (-2.27%)
enterprise/internal/codeintel/store/indexes.go 92.79% <0.00%> (-0.07%)