Open dvpierce opened 7 months ago
I have this issue too, it seems like it's expecting parentheses.
Hello, thanks for the report I'm not able to reproduce. Does the bug still occur? If so, could you provide some piece of config that's causing it?
Hi @kkozik-amplify ,
I just hit the same and have managed to update the test case to show the failure (see this branch). I have been unable to find a solution so far as I am not that familiar with lark.
@grahamhar Hi, thanks for the test case.
It looks like the issue is caused by incorrect definition in the grammar file - we will look into this.
As a workaround, wrapping conditional expression into parentheses should help:
operator = (local.assertion == 1 ? local.yes : local.no)
It does appear that the files parse OK when we downgrade to 4.3.0
I have been doing a little more testing and we have some conditionals that have embedded conditionals too.
operator = local.assertion == 1 ? local.some_logic == 2 ? local.yes : "custom" : local.no
Hi there,
we also had this issue.
We currently downgraded to 4.3.0
. Any higher version (4.3.1, 4.3.2, 4.3.3) didn't work
We could only reproduce this error this way in our unit test:
module "unittest" {
nested = {
nested_attribute = var.nested == null ? null : {
publisher = var.nested.publisher
}
nested_after_conditional_object = var.variable
}
}
and (basically the same)
module "unittest" {
nested = {
nested_attribute = var.attr == null ? local.yes : local.no
nested_after_conditional_object = var.variable
}
}
which would fail with lark.exceptions.UnexpectedToken: Unexpected token Token('__ANON_3', 'nested_after_conditional_object')
other conditionals wouldn't cause issues.
The workaround with parentheses also worked, but is not a viable option for us
These didn't fail:
almost the same as above, but without the attribute after the conditional (nested_after_conditional_object
)
module "unittest" {
nested = {
nested_attribute = var.nested == null ? null : {
publisher = var.nested.publisher
}
}
}
some other conditionals we tested (we also tested the failing one with parentheses, which passes)
module "unittest" {
conditional = var.question ? one(azurerm_resource_group.rg[*].name) : var.no
nested_conditional = var.question != null ? var.yes != null ? var.yesyes : local.yesno : var.no
attribute = var.attribute == null ? null : {
publisher = var.attribute.publisher
}
after_attribute = var.variable
}
(this module syntax is of course not correct, but it doesn't matter for the parser) This is pretty much the test-case that grahamhar added.
Here is another file where this happens: https://github.com/Azure/terraform-azurerm-naming/blob/0.4.1/main.tf
here is also an example:
locals {
a = {
b = terraform.workspace == "production" ? "x" : "y"
c = terraform.workspace == "production" ? "n" : "m"
}
}
parsing fails only if it is nested and we have two with the ? : syntax
This seemingly is related to / the same root cause as https://github.com/amplify-education/python-hcl2/issues/163 https://github.com/amplify-education/python-hcl2/issues/140 In short parsing of expressions seems to be problematic in 4.3.1+
Error:
When parsing a file that has a conditional assignment in it.
key = value == null ? "" : someothervalue
Any idea how I might fix or work around this? Or if a library fix is needed (or can even address this?)