hashicorp / hcl2

Former temporary home for experimental new version of HCL
https://github.com/hashicorp/hcl
Mozilla Public License 2.0
373 stars 66 forks source link

Spurious "Invalid character" errors at EOF #15

Closed apparentlymart closed 6 years ago

apparentlymart commented 6 years ago

In a file in the Google Cloud SQL example on Terraform Registry, the parser seems to be getting confused about something, since it's reporting dozens of error messages like the following (two variants seen):

Error: Invalid character

  on .terraform/init-from-module/root/GoogleCloudPlatform-terraform-google-sql-db-688a320/variables.tf line 136:

This character is not used within the language.
Error: Invalid character

  on .terraform/init-from-module/root/GoogleCloudPlatform-terraform-google-sql-db-688a320/variables.tf line 136:

The "`" character is not valid. To create a multi-line string, use the
"heredoc" syntax, like "<<EOT".

In both cases, the source reference is at the end of the file and so this suggests that the parser is entering recovery mode at some earlier point and then some other parser component is getting confused and not aborting properly in that mode.

The mention of the backtick character in some of the error messages may be a clue, since backticks are used in some of the description strings. Perhaps the string parser is getting confused by those backticks.


Errors like the following are also being reported, due to the new parser no longer accepting the non-idiomatic form of unquoted block labels:

Error: Attribute or block definition required

  on .terraform/init-from-module/root/GoogleCloudPlatform-terraform-google-sql-db-688a320/variables.tf line 17:
  17: variable project {

An attribute or block definition is required here. To define an attribute, use
the equals sign "=" to introduce the attribute value.

Error: Attribute or block definition required

  on .terraform/init-from-module/root/GoogleCloudPlatform-terraform-google-sql-db-688a320/variables.tf line 22:
  22: variable region {

An attribute or block definition is required here. To define an attribute, use
the equals sign "=" to introduce the attribute value.

Error: Attribute or block definition required

  on .terraform/init-from-module/root/GoogleCloudPlatform-terraform-google-sql-db-688a320/variables.tf line 27:
  27: variable name {

An attribute or block definition is required here. To define an attribute, use
the equals sign "=" to introduce the attribute value.

However, this particular error is also visible in that repository's outputs.tf file and yet it doesn't also exhibit the strange "Invalid character" error behavior, so possibly there is something else going on here. There are no backticks in outputs.tf, so that lends further credence to the idea that the backticks are triggering the weird behavior.

apparentlymart commented 6 years ago

This is also occurring in the alibaba/ecs-instance/alicloud module:

Error: Invalid character

  on .terraform/init-from-module/root/alibaba-terraform-alicloud-ecs-instance-063c382/main.tf line 88:
  88: }

This character is not used within the language.

There are no backticks in this file. In this case the error message appears only once, however.

apparentlymart commented 6 years ago

In the Alicloud case it appears that the error was caused as a side-effect of #16, which is now fixed.

apparentlymart commented 6 years ago

The cause of this is a quoted percent sign.

Our new parser uses %{ as the introducer for template control sequences, whereas previously it was interpreted literally. Our intent here is that a % not followed by a { will be treated literally, but the way that is implemented causes problems here because the % consumes its following " in order to check that it isn't a {, which in turn prevents the string terminator from being detected:

Error: Unterminated template string

  on weird.hcl line 63, in variable "user_host":
  63:   default     = "%"
  64: }

No closing marker was found for the string.

Unfortunately this ends up leaving things in a broken state because the scanner thinks it is still reading an embedded template while the parser has moved on and returned back to expression parsing, causing the following tokens to make no sense.

apparentlymart commented 6 years ago

This is fixed in 92456935b84870414bc208a88b12d0f99c1a0638.