Using gohcl, escape characters required for HCL parsing remain in the decoded string field

[sigil66]

Given the following string in HCL2 the \ required to parse \/:

"^whatever\\/.*$"

When decoding with gohcl into a struct the resulting string within the struct still contains the extra \

Acl: (*model.Acl)(0xc4201b2080)({
  Resources: ([]*model.Resource) (len=5 cap=5) {
   (*model.Resource)(0xc420157d70)({
    Pattern: (string) (len=13) "^whatever\\/.*$",
    Permissions: ([]*model.Permission) (len=2 cap=2) {
     (*model.Permission)(0xc4201b40f0)({
      Authority: (string) (len=15) "role:nacho_rw",
      Actions: ([]string) (len=2 cap=2) {
       (string) (len=4) "pull",
       (string) (len=4) "push"
      }
     }),

I would expect that the when decoding the string escape is removed?

[sigil66]

Looking at https://github.com/hashicorp/hcl2/blob/5ca9713bf06addcefc0a4e16f779e43a2c88570c/hcl/hclsyntax/scan_string_lit.rl

The syntax doesn't seem to support a way of encoding a single backslash?

[apparentlymart]

Thanks for reporting this, @sigil66!

This looks like a parser bug. It is indeed intended that the extra backslash would be removed here.

The relevant part of the code is here:

https://github.com/hashicorp/hcl2/blob/5f8ed954abd873b2c09616ba0aa607892bbca7e9/hcl/hclsyntax/parser.go#L1590-L1592

I'm not sure yet what's causing this but I'll dig into this some more soon.

[apparentlymart]

Hi again, @sigil66!

Looking at this again with fresh eyes, I think the string is actually as expected, and it's actually just the dump syntax (is that go-spew?) that is making it seem incorrect:

Pattern: (string) (len=13) "^whatever\\/.*$",

This line is using Go's own string quoting syntax. If we peel that off by removing the quotes and processing all the escapes, I think the string looks like this:

^whatever\/.*$

Does that seem right? This could be confirmed by printing out the string alone, rather than printing it out as part of a larger dump in quotes.

[sigil66]

I don't think so, as I encountered the issue trying to pass parsed string to utilize in a go regex match which generated the original error.

I can provide the offending code if this helps.

[apparentlymart]

If you have a small reproduction case then I'd be happy to take a look at it!