Improve error when using object locals in field name expressions or for specs

[mark-rushakoff]

I was actually trying to use an object comprehension with a top level function, like:

function(j) {
  local obj = std.parseJson(j),

  [key]: someOtherFunction(key) 
  for key in std.objectFields(obj)
}

But then I was able to minimize the reproducer to:

{
  local x = ['a'],

  [key]: key
  for key in x
}

Which errors with

/tmp/f.jsonnet:5:14-15 Unknown variable: x

  for key in x

I expected this form to work.

If this is behaving as intended, perhaps there is a way the error message could be improved?

Eventually I figured out that I can move the local variable declaration outside of the scope of the object comprehension:

(
  local x = ['a'];
  {
    [key]: key
    for key in x
  }
)

Which results in

{
   "a": "a"
}

as expected. But this approach was very unintuitive and took me around 45 minutes to debug, even though I've been working with Jsonnet on a near-daily basis for 6+ months.

[sbarzowski]

Thanks for the report. It's good to get feedback about these things!

In this case, the behavior is intentional and consistent with the scoping rules for normal objects.

{
    local var = <var_expr>
    [key]: <val_expr> for key in <arr_expr>
}

The local var is a part of an object (<var_expr> can access self, etc.), so it is available only when the object is constructed. On the other hand arr_expr is needed for constructing the object, so it cannot have access to the object or we would have a circular dependency. For this reason the scope of arr_expr is outside of an object. It's the same with field names in regular object literals - you cannot make a field name depend on an object local, but you can make it depend on a local outside of the object (because the field name needs to be calculated to construct the object).

Please let us know if it's more clear now.

Note: we have an actual outstanding bug related to local in object comprehensions: #358, but it's not related to your issue.

[mark-rushakoff]

Thanks, the explanation confirmed my eventual suspicions about the scope details. I'm sure I'll run into this issue again, but next time I'll quickly understand what to do to avoid it.

I did run into #358 while following up with what I was originally trying to do, but it was late and I didn't look through open issues.

I think #386 would help, although we are not yet running the linter. I believe I tried running the linter from v0.14 and I don't believe it was providing correct feedback.

An improved error message here, actually built into jsonnet, would provide faster feedback. But I understand that could be a slippery slope of inspecting adjacent scopes to provide detailed actions when compilation fails. Maybe instead of "Unknown variable: x", something more like "No variable named x in scope of object comprehension" would have been sufficiently detailed to hint that it was a scope problem.

A large factor of why this was difficult for me to debug, was how much else was going on in the adjacent code. Did I misspell a variable name? Was it the way I was invoking jsonnet with --tla-str-file? Was it something wrong with using a function call in an object comprehension?

[sparkprime]

This trips so many people up that it's probably worth having the extra complexity in the static checking to provide the better error message.