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.

Sign up for GitHub

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

Jump to bottom

Error if attempting to use marked value as key #434

Merged
merged 1 commit into from
Dec 17, 2020
Merged

Error if attempting to use marked value as key #434

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions hclsyntax/expression.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -825,6 +825,19 @@ func (e *ObjectConsExpr) Value(ctx *hcl.EvalContext) (cty.Value, hcl.Diagnostics
continue
}

if key.IsMarked() {
diags = append(diags, &hcl.Diagnostic{
Severity: hcl.DiagError,
Summary: "Marked value as key",
Detail: "Can't use a marked value as a key.",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize this is a late-arriving review given that this is already merged and queued for release, but... it feels weird to me to talk about "marked values" in user-facing error messages, because this idea of marks has so far been just an implementation detail.

Based on how marks behave down at the cty layer I would've expected any marks from the keys to be silently transferred to be marks on the map itself, rather than this producing an error. 🤔

I think if we were to decide to change this later then it wouldn't be considered a breaking change because it would turn something that was formerly an error into something that is now a "more correct" success (though of course that's a matter of opinion), so I think it'd be okay to go ahead with this in the meantime, but I'd like to talk this out a little and see what the tradeoffs would be for the alternative behavior I proposed above.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've put this on my backlog to re-visit -- thanks for sharing this feedback, I also don't like making errors in HCL mention marks (also because they have to disclose that there are marks in a general sense, whereas in Terraform, they can be specific to what kind of marks are present, which currently only includes sensitive).

The idea of preserving the marks and then marking the whole object mimics other behavior we have, and I appreciate the input that we won't have to consider it a breaking change.

Subject: item.ValueExpr.Range().Ptr(),
Expression: item.KeyExpr,
EvalContext: ctx,
})
known = false
continue
}

var err error
key, err = convert.Convert(key, cty.String)
if err != nil {
Expand Down
13 changes: 13 additions & 0 deletions hclsyntax/expression_test.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -506,6 +506,19 @@ upper(
}),
0,
},
{
// Marked values as object keys
`{(var.greeting) = "world", "goodbye" = "earth"}`,
&hcl.EvalContext{
Variables: map[string]cty.Value{
"var": cty.ObjectVal(map[string]cty.Value{
"greeting": cty.StringVal("hello").Mark("marked"),
}),
},
},
cty.DynamicVal,
1,
},
{
`{"${var.greeting}" = "world"}`,
&hcl.EvalContext{
Expand Down