With changes to the lazy evaluation, the evaluation order is no longer fixed - this means that we can follow long and confusing paths to get to an error.

Because of the co-recursive nature of the lazy evaluation, we need to take special care that the original HCL diagnostics are not discarded and are preserved so that the original source of the error can be detected. Preserving the full trace is not necessary, and probably not useful to the user - all of the file that is not lazily loaded will be eagerly loaded after all struct blocks are loaded - so the error would be found regardless.

For example, in the following docker-bake.hcl:

x = x
target "test" {
  dockerfile = x
}

We expect an error view like:

docker-bake.hcl:1
--------------------
   1 | >>> x = x
   2 |     
   3 |     target "test" {
--------------------
ERROR: docker-bake.hcl:1,5-6: Invalid expression; variable cycle not allowed for x

But in v0.10 we get:

docker-bake.hcl:4
--------------------
   2 |     
   3 |     target "test" {
   4 | >>>   dockerfile = x
   5 |     }
   6 |     
--------------------
ERROR: docker-bake.hcl:4,16-17: Invalid expression; docker-bake.hcl:1,5-6: Invalid expression; variable cycle not allowed for x

This occurs because we double wrap the error with two layers of hcl.Diagnostics, which we can avoid by only wrapping if the target error is not already an hcl.Diagnostics error type.