-
Notifications
You must be signed in to change notification settings - Fork 601
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
Block's OpenBraceRange.Start
differs if a proper block precedes it or not
#708
Comments
Actually now that I look at it some more it seems like both ranges are wrong. And from debugging I see all the ranges are identical to each other. :P Lines 362 to 374 in d20d07f
|
When there's no brace at the end of the header, the parser performs recovery and then returns a very stubby fake As far as the parser is concerned, this block has no braces at all (the brace is on the next line, but the parser only uses one token of lookahead so it's currently "looking at" the newline) and so it's using the ident range as a placeholder so that at least there's something to return. Since the It could perhaps instead have returned the position of the newline token as a way to say where the brace ought to have been --
Unlike with #702, because this is error recovery behavior rather than ranges reported by a successful parse I don't think it's reasonable to expect it to return something sensible in all cases and so I dunno whether it's actually worth trying to improve this, but above are my ideas on how to improve it if there's a strong enough reason to justify doing it. |
I have two different HCL blocks.
Although both of the
bad
blocks look similar, theirBlock.OpenBraceRange.Start
value is quite different. The first one seems to believe it exists at the start of the file (essentiallyhcl.InitialPos
) but the second one seems to have something more sane as a response.The text was updated successfully, but these errors were encountered: