Skip to content

search: introduce annotations for terms

Administrator requested to merge rvt/query-term-annotations into master

Created by: rvantonder

This PR introduces a type to attach information as "annotation" to individual nodes in a query. The only annotation type introduced in this PR is Labels, which allows to attach general-purpose information to a query. The annotation type is expected to expand, as we will certainly find other annotations useful, for example location Ranges of terms in a query, errors, or suggestions specific to a term. For simplicity this PR only adds Annotation to Pattern nodes, but will later be a member of all query nodes.

I've added a labels that help drive the parser logic and interpretation (about quoting and heuristics). This is more elegant than the previous ad-hoc pattern type with Quoted member, and I've refactored everything around the changes. This comes after thinking more about managing bookkeeping and parser options (I think @keegancsmith asked about a more 'direct' or simpler way, and I think this helps with it).

Review this PR by commit.

You may be curious what guides the type definitions of nodes. I.e., whether information about a node is an "annotation" versus a top-level member in the definitions below. The gist is that all parts of the abstract syntax should be exposed at the top level, and associated information (location ranges, and other labels) are annotations. This is why "Negated" is not, for example, a label.

// Pattern is a leaf node of expressions representing a search pattern fragment. 
type Pattern struct {                                                                                                                                                                 
        Value      string
        Negated    bool
        Annotation annotation
} 

// Parameter is a leaf node of expressions representing a parameter of format "repo:foo".                                                                                             
type Parameter struct {                                                                                                                                                               
        Field   string `json:"field"`
        Value   string `json:"value"`
        Negated bool   `json:"negated"`
        Annotation annotation
}

These definitions lead to visitor interfaces that can distinctly expose what forms part of the tree structure, versus other information that is (only) associated with it. So the intent is to create clearer ways of interacting with the query rather than bundling all information into one struct.

Merge request reports