LocationRange is missing for object fields

[buremba]

In some cases, the ast.Node instances (especially the literals) returned by SnippetToAST don't have LocRange as seen in the following picture:

In this case, it's a ast.LiteralString inside the Name of ast.DesugaredObjectField. Is this expected?

[sbarzowski]

It should have the LocRange (all expressions should ideally have a locrange). In case of desugared expressions it's not always obvious to what part of the original code it maps, but it can always be "the smallest expression in the original code to which it can be traced".

In this particular case, it's not a very big deal, but may be worth fixing while doing other cleanup (unless we know it's breaking something).

[buremba]

@sbarzowski My understanding is that this AST is the representation of the original source code so I'm not sure why it's not obvious to what part of the original code the AST node maps. It would be great if you can give an example of such a case.

For this particular case, I'm working on IDE integration so the location information is crucial for me to find out where the cursor is located in the AST so that I can implement features such as info on hover, auto-complete, etc.

[sbarzowski]

There are two kinds of ASTs:

• Raw AST – 1-1 with the code, allows producing the original source code (maybe with some minor formatting changes). This is not exposed in the public API currently.
• Desugared AST – postprocessed AST, which uses only a subset of the language.

The purpose of desugared AST is to minimize the number of cases to handle in the interpreter, static analysis etc. For example it doesn't distinguish between: { a: 42 }, { "a": 42 } and { ["a"]: 42 } – it's all normalized to the last, most general form. Sometimes expressions in the desugared AST don't have matching expressions in the raw AST. For example a in { a: 42 } is not an expression on its own, but it maps to an expression (string literal) after desugaring.

Here the desugared name expression is created: https://github.com/google/go-jsonnet/blob/v0.16.0/internal/program/desugarer.go#L77. The makeStr function doesn't attach location information to the created string literal. We only have information about the location of the whole field when { a: "foo" }. syntax is used. So to fix it we would need to:

1. Add id-key location to raw AST (https://github.com/google/go-jsonnet/blob/v0.16.0/ast/ast.go#L595).
2. Save the id-key location in the raw AST (need to change the parser here: https://github.com/google/go-jsonnet/blob/v0.16.0/internal/parser/parser.go#L500).
3. Make sure it's propagated to the desugared AST (https://github.com/google/go-jsonnet/blob/v0.16.0/internal/program/desugarer.go#L77).

Let me know if it's more clear now.

[buremba]

That makes sense, thanks! In that case, I should probably work with the output of the internal function parser.SnippetToRawAST, not SnippetToAST for a proper IDE integration.