Skip to content

gohcl: allow gohcl to parse hcl.Range objects for blocks and attributes#703

Merged
liamcervante merged 2 commits intohashicorp:mainfrom
liamcervante:liamcervante/gohcl-range
Nov 19, 2024
Merged

gohcl: allow gohcl to parse hcl.Range objects for blocks and attributes#703
liamcervante merged 2 commits intohashicorp:mainfrom
liamcervante:liamcervante/gohcl-range

Conversation

@liamcervante
Copy link
Copy Markdown

@liamcervante liamcervante commented Oct 24, 2024

This PR updates the gohcl package so that users can automatically extra the source ranges for blocks and attributes using the following new tags:

  • def_range
  • type_range
  • label_range
  • attr_range
  • attr_name_range
  • attr_value_range

There's not breaking changes or backwards compatibility issues here, this is just all additive changes.

@liamcervante liamcervante marked this pull request as draft October 24, 2024 15:54
@apparentlymart
Copy link
Copy Markdown
Contributor

apparentlymart commented Oct 24, 2024

In case it's interesting: I wrote a different take on this use-case a while back using a generic type to annotate a value with a range, rather than using separate fields for the range: #516

A test in that PR shows how it would be used:

hcl/gohcl/with_range_test.go

Lines 16 to 50 in 6e417e5

type Config struct {
Name WithRange[string] `hcl:"name"`
Number int `hcl:"number"`
}
configSrc := `
name = "Gerald"
number = 12
`
f, diags := hclsyntax.ParseConfig([]byte(configSrc), "test.hcl", hcl.InitialPos)
if diags.HasErrors() {
t.Fatalf("unexpected errors: %s", diags)
}
var config Config
diags = DecodeBody(f.Body, nil, &config)
if diags.HasErrors() {
t.Fatalf("unexpected errors: %s", diags)
}
want := Config{
Name: WithRange[string]{
Value: "Gerald",
Range: hcl.Range{
Filename: "test.hcl",
Start: hcl.Pos{ Line: 2, Column: 12, Byte: 12 },
End: hcl.Pos{ Line: 2, Column: 20, Byte: 20 },
},
},
Number: 12,
}
if diff := cmp.Diff(want, config); diff != "" {
t.Errorf("incorrect result\n%s", diff)
}

Thankfully it's now probably been long enough since Go 1.18 was released that it wouldn't be so important to hide the new generic type from older Go compilers.

Both of them seem like plausible designs, of course. I expect it's a matter of taste which one someone would prefer.

@liamcervante
Copy link
Copy Markdown
Author

liamcervante commented Oct 25, 2024

Thanks for the extra context @apparentlymart! We don't have a confirmed use case for this just yet but I'm investigating something that might need it and wanted to make sure it was possible 😅 It'll be good to have the alternate take to think about if/when I come back and try and get this merged!

@liamcervante liamcervante requested a review from a team November 18, 2024 16:18
@liamcervante liamcervante marked this pull request as ready for review November 18, 2024 16:18
@liamcervante liamcervante merged commit a369057 into hashicorp:main Nov 19, 2024
@liamcervante liamcervante deleted the liamcervante/gohcl-range branch November 19, 2024 11:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@jbardin jbardin jbardin approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@liamcervante @apparentlymart @jbardin