Open KGuillemot opened 1 year ago
Actually, when using the following rulebase :
version=2 rule=:% {"name":"numbers", "type":"repeat", "parser":[ {"type":"number"}, {"type":"literal", "text":":"}, {"type":"number", "name": "."} ], "while":[ {"type":"literal", "text":", "} ] }%
And the following line to parse :
1:2, 3:4, 5:6, 7:8
I get the following error :
$ echo '1:2, 3:4, 5:6, 7:8' | lognormalizer -r ./test.rb liblognorm error: rulebase file ./test.rb[12]: 'repeat' parser supports dot name only if single parser is used in 'parser' part, invalid construct: [ { "type": "number" }, { "type": "literal", "text": ":" }, { "type": "number", "name": "." } ] liblognorm error: rulebase file ./test.rb[12]: repeat parser needs 'parser','while' parameters Erreur de segmentation
The error 'repeat' parser supports dot name only if single parser is used should be raised only if 2 parsers have a name configured.
After fixing, when using the rule and line listed above, the error does not raise and the parsing behavior is as expected.
$ echo '1:2, 3:4, 5:6, 7:8' | lognormalizer -r ./test.rb { "numbers": [ "2", "4", "6", "8" ] }
After fix, the error correctly raises when multiple parsers use a name :
version=2 rule=:% {"name":"numbers", "type":"repeat", "parser":[ {"type":"number", "name": "n1"}, {"type":"literal", "text":":"}, {"type":"number", "name": "."} ], "while":[ {"type":"literal", "text":", "} ] }%
$ echo '1:2, 3:4, 5:6, 7:8' | lognormalizer -r ./test.rb liblognorm error: rulebase file ./test.rb[12]: 'repeat' parser supports dot name only if single parser is used in 'parser' part, invalid construct: [ { "type": "number", "name": "n1" }, { "type": "literal", "text": ":" }, { "type": "number", "name": "." } ] liblognorm error: rulebase file ./test.rb[12]: repeat parser needs 'parser','while' parameters Erreur de segmentation
Actual behavior
Actually, when using the following rulebase :
And the following line to parse :
I get the following error :
The error 'repeat' parser supports dot name only if single parser is used should be raised only if 2 parsers have a name configured.
Fixed behavior
After fixing, when using the rule and line listed above, the error does not raise and the parsing behavior is as expected.
Non-regression tests
After fix, the error correctly raises when multiple parsers use a name :