Skip to content

search: expose parse tree via GQL [3/3]

Administrator requested to merge rvt/query-info-via-gql into master

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