-
Notifications
You must be signed in to change notification settings - Fork 584
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.
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
hclsyntax: Recovery of incomplete ConditionalExpr
#643
Comments
Thanks for raising this! Again I find myself unsure about what we can do here, but it seems worth a try. The challenges with this sort of recovery are always of a similar genre: we need to make some assumptions about what's likely to be coming up so that we can go hunting forward for tokens without any higher-level grammar to guide us, but to try to be conservative so that we don't cause the remaining parsing work to begin in a very strange place in the token stream where the subsequent parsing will behave badly. In this case it seems like we'd need for the conditional expression parser to check for errors when trying to parse the second expression (the one after the As you say, I think The case where the predicate expression itself is omitted (i.e. the entire expression starts with a |
Background
Similar to some earlier issues, we found some more edge cases while implementing support for
ConditionalExpr
in the Language Server.hashicorp/hcl-lang#326
ConditionalExpr
attr = ? var.foo : var.bar
attr = var.foo ? : var.bar
attr = var.foo ? var.bar :
attr = var.foo ?
Traversal
(with trailing dot) inside otherwise completeConditionalExpr
attr = var. ? var.foo : var.bar
attr = var.foo ? var. : var.bar
attr = var.foo ? var.bar : var.
As with other reports related to recovery from incomplete configuration, the context is - again - enabling completion. Users would reasonably expect to be offered relevant completion in the above contexts, because it is exactly the nature of completion to complete the incomplete configuration.
Proposal
Regarding the incomplete
Traversal
specifically - I remember seeing other contexts where the trailing dot is simply ignored and the outer expression is recovered and so is the attribute as whole. I am therefore a little more hopeful we could do something about these edge cases.The other ones like
attr = ? var.foo : var.bar
I would think could still be reported asConditionalExpr
but with eithernil
or some kind of empty expressions (I've seenLiteralValueExpr{}
used before in similar contexts, such asattr =
).The only incomplete expression I can see being really difficult or maybe impossible to deal with meaningfully is the one which is missing a control character
:
(attr = var.foo ?
) because there could be lack of confidence in what kind of expression is it even supposed to be.The text was updated successfully, but these errors were encountered: