-
Notifications
You must be signed in to change notification settings - Fork 583
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 outer ObjectConsExpr
with empty TemplateExpr
#641
Comments
Thanks for sharing this, @dbanck. The comment in the last source snippet you shared matched what was my initial instinct while thinking about this: I expect it's the way it is because symmetrical bracket tokens tend to be a more reliable heuristic for recovery than single tokens like We could certainly try seeing how it behaves trying to use the terminating comma as the recovery anchor. I think the trick will be how it ends up dealing with the situation where the remainder of the invalid expression itself contains a comma somewhere, such as if there's a nested object constructor, nested tuple constructor, function call, or Of course, everything about this recovery logic is heuristic-based rather than exact anyway -- if the token stream isn't valid we're always doing a fair amount of guessing -- so I think the best we can do here is experiment with some different examples and see how they each behave, and then decide whether the cure seems better or worse than the disease. |
During the work to support template expressions in the language server, we discovered a different recovery behavior when dealing with empty template expressions.
"Regular" / Expected
In this case, we get a diagnostic for an invalid expression, as expected, but the parsed configuration still contains a
TemplateExpr
with three parts. The secondLiteralValueExpr
corresponds to the empty template expression${}
.Inside
ObjectConsExpr
If we encounter the empty template expression inside an object value, the parser stops and recovers the object without any items. All entries before the template expression are part of the result, all items after it are lost.
This looks a bit similar to #597, but in this case the configuration is nearly valid and works in the context of a simple attribute.
Proposal
Explore whether it might be possible to handle the empty template expression differently than the default recovery on invalid value expression?
hcl/hclsyntax/parser.go
Lines 1496 to 1505 in c964a71
The text was updated successfully, but these errors were encountered: