Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[v0.10] cherry-picks for v0.10.3 #1609

Merged
merged 8 commits into from
Feb 16, 2023
Merged

Conversation

jedevc and others added 7 commits February 8, 2023 14:29
Signed-off-by: Justin Chadwell <[email protected]>
(cherry picked from commit 48357ee)
Signed-off-by: CrazyMax <[email protected]>
(cherry picked from commit 0e544fe)
Signed-off-by: Justin Chadwell <[email protected]>
(cherry picked from commit 07548bc)
With changes made to allow lazy evaluation, we were early exiting if an
undefined name was detected, either for a variable or a function.

This had two key implications:

1. The error messages changed, and became significantly less
   informative.

   For example, we went from:

   > Unknown variable; There is no variable named "FO". Did you mean "FOO"?, and 1 other diagnostic(s)

   To

   > Invalid expression; undefined variable "FO"

2. Any issues in our function detection from funcCalls which cause JSON
   functions to be erroneously detected cause invalid functions to be
   resolved, which causes new name resolution errors.

To avoid the above problems, we can defer the error from an undefined
name until HCL evaluation - which produces the more informative errors,
and does not suffer from incorrectly detecting JSON functions.

Signed-off-by: Justin Chadwell <[email protected]>
(cherry picked from commit dc8a2b0)
Signed-off-by: CrazyMax <[email protected]>
(cherry picked from commit a8eb2a7)
Signed-off-by: CrazyMax <[email protected]>
(cherry picked from commit fd58841)
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.

Signed-off-by: Justin Chadwell <[email protected]>
(cherry picked from commit fbb4f4d)
@jedevc jedevc self-requested a review February 16, 2023 11:16
@jedevc jedevc marked this pull request as ready for review February 16, 2023 11:16
@jedevc

This comment was marked as resolved.

To give us the option later down the road of producing recommended OCI
names in BuildKit (using com instead of vnd, woops), we need to update
Buildx to be able to process both.

Ideally, if a Buildx/BuildKit release hadn't been made we could just
switch over, but since we have, we'd need to support both (at least for
a while, eventually we could consider deprecating+removing the vnd
variant).

Signed-off-by: Justin Chadwell <[email protected]>
(cherry picked from commit 642f28f)
@crazy-max crazy-max merged commit f2feea8 into docker:v0.10 Feb 16, 2023
@crazy-max crazy-max deleted the 0.10.3_cherry_picks branch February 16, 2023 13:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants