Jira (PUP-6282) Confusing error message when doing a variable assignment followed by bare hash with explicitly quoted keys
Title: Message Title Henrik Lindberg commented on PUP-6282 Re: Confusing error message when doing a variable assignment followed by bare hash with explicitly quoted keys neat! Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6282) Confusing error message when doing a variable assignment followed by bare hash with explicitly quoted keys
Title: Message Title
Peter Huene commented on PUP-6282
Re: Confusing error message when doing a variable assignment followed by bare hash with explicitly quoted keys
I have a simple fix to improve the native compiler's error message for a resource _expression_ missing a colon:
Error: test.pp:1:12: node 'peterhu': expected ':' but found '}'.
file { foo }
^
This was solved with Spirit's ability to do a negation match on a rule without consuming a token, i.e. the resource body rule was updated to be "an _expression_ followed by something that isn't token '=>' (non-consuming) expected to be followed by token ':' expected to be followed by attributes".
Thus if the token following foo in the above example is =>, it gracefully fails to match the resource body rule (and thus the resource _expression_ rule) and continues to match other rules; however, if the token is not =>, it is expected to be :, thus failing with a better error message where previously it was falling back to matching the name rule and then the hash rule (where this is an expectation point that a => token comes after an _expression_).
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e
Jira (PUP-6282) Confusing error message when doing a variable assignment followed by bare hash with explicitly quoted keys
Title: Message Title
Henrik Lindberg commented on PUP-6282
Re: Confusing error message when doing a variable assignment followed by bare hash with explicitly quoted keys
Thanks Peter Huene
At some point I hope we can get rid of the resource default, or change it so that it becomes:
_expression_ '{' LiteralDefault ':' '}'
There is also the bigger idea of changing the compiler to allow duplicate/merging resources in which case the entire concept of default should change from what it is now. (At runtime there is also the issue of dynamic scoping; so defaults are causing problems all over the place).
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6282) Confusing error message when doing a variable assignment followed by bare hash with explicitly quoted keys
Title: Message Title
Peter Huene commented on PUP-6282
Re: Confusing error message when doing a variable assignment followed by bare hash with explicitly quoted keys
The native parser gives this for both examples:
Notice: compiling for node 'peterhu-osx.delivery.puppetlabs.net' with environment 'production'.
Error: example.pp:6:43: node 'peterhu-osx': expected '=>' but found '}'.
}.each |$x| { notify { "${x[0]}: ${x[1]}" } }
^
Notice: compilation failed with 1 error and 0 warnings.
That is because of the missing : after the resource title, forcing the lookahead for a resource declaration to fail, failing back to assuming it is a name followed by a hash (hence the "expected a =>" bit).
Add Comment
Jira (PUP-6282) Confusing error message when doing a variable assignment followed by bare hash with explicitly quoted keys
Title: Message Title
Henrik Lindberg commented on PUP-6282
Re: Confusing error message when doing a variable assignment followed by bare hash with explicitly quoted keys
It is incredibly complex to do anything about this with the current technology used for parsing in the Ruby implementation (racc). More lookahead is needed to be able to tell the expressions apart than what is offered in racc (limited to 1 token across rules), and there is no backtracking.
Thus, we had to choose our poison; a change will lead to either lower quality in error messages for other types of grammatical corner cases, or that some expressions cannot be freely used. One type of _expression_ that is causing major grammatical headache is the resource default _expression_ i.e.
Typename { attr => _expression_, ... }
This because, that makes the resource attribute body and a hash look exactly the same. The grammar has to pick one. What makes it worse is that the resource form allows bare words only, including keywords for the attribute names which necessitates the upfront decision. In a resource _expression_ it is also allowed to use the +> attribute assignment operator.
If we were to get rid of the resource default, we would still have issues recognizing a titled resource body since quite a bit of lookahead is needed to find the ':' that terminates the title (but it could be doable). It would be quite a breaking change though.
There may be opportunity to try to understand more about the parse context when there is a syntax error to try to figure out something more intelligent to say than "syntax error". Attempts at using the available information has not led very far though - so far I have only been able to come up with output that would be even more confusing - as when the error occurs there are often dozens of choices to consider - all equally wrong.
Puppet is quite complicated to parse and in order to do a good job needs a more comprehensive parser technology than what is available with reasonable performance in Ruby. We are working on a native C++ implementation in order to both increase performance and improve on quality on diagnostic output.
Ping Peter Huene, how is the native parser doing on the expressions in the example?
Note that there is an additional error as there is a colon missing after the title in the notify - it should read like this:
notify { "${x[0]}: ${x[1]}" : }
Jira (PUP-6282) Confusing error message when doing a variable assignment followed by bare hash with explicitly quoted keys
Title: Message Title
Ryan Whitehurst created an issue
Puppet / PUP-6282
Confusing error message when doing a variable assignment followed by bare hash with explicitly quoted keys
Issue Type:
Bug
Assignee:
Unassigned
Created:
2016/05/09 6:05 PM
Priority:
Normal
Reporter:
Ryan Whitehurst
Sort of hard to explain the scenario, but here's an example:
$foo = 'bar'
{
'ONE' => 'a',
'TWO' => 'b',
