![]() |
Qucs-S S-parameter Viewer & RF Synthesis Tools
|


Public Member Functions | |
| test_inner_rule_succeeding (self) | |
| test_rewinding (self) | |
| test_no_named_rule_succeeding (self) | |
| test_parse_with_leftovers (self) | |
| test_favoring_named_rules (self) | |
| test_line_and_column (self) | |
Tests for reporting parse errors
| parsimonious.tests.test_expressions.ErrorReportingTests.test_favoring_named_rules | ( | self | ) |
Named rules should be used in error messages in favor of anonymous ones, even if those are rightward-progressing-more, and even if the failure starts at position 0.
| parsimonious.tests.test_expressions.ErrorReportingTests.test_inner_rule_succeeding | ( | self | ) |
Make sure ``parse()`` fails and blames the rightward-progressing-most named Expression when an Expression isn't satisfied. Make sure ParseErrors have nice Unicode representations.
| parsimonious.tests.test_expressions.ErrorReportingTests.test_line_and_column | ( | self | ) |
Make sure we got the line and column computation right.
| parsimonious.tests.test_expressions.ErrorReportingTests.test_no_named_rule_succeeding | ( | self | ) |
Make sure ParseErrors have sane printable representations even if we never succeeded in matching any named expressions.
| parsimonious.tests.test_expressions.ErrorReportingTests.test_parse_with_leftovers | ( | self | ) |
Make sure ``parse()`` reports where we started failing to match, even if a partial match was successful.
| parsimonious.tests.test_expressions.ErrorReportingTests.test_rewinding | ( | self | ) |
Make sure rewinding the stack and trying an alternative (which progresses farther) from a higher-level rule can blame an expression within the alternative on failure. There's no particular reason I suspect this wouldn't work, but it's a more real-world example than the no-alternative cases already tested.