| commit | 208d018cd97cde0c7dc42aba2985583759925778 | |
| author | Eric Lippert <ericlippert@fb.com> | |
| Mon, 11 Sep 2017 08:08:26 +0000 (11 01:08 -0700) | ||
| committer | Hhvm Bot <hhvm-bot@users.noreply.github.com> | |
| Mon, 11 Sep 2017 08:20:33 +0000 (11 01:20 -0700) | ||
| tree | 1ec3aed99d156df0e7735cce3c55ca0114d5cb6b | treesnapshot (tar.gz zip) |
| parent | 311faed7f02dc173d4b0c3ad9593cb54341536e6 | commitdiff |
Improve error reporting APIs for full-fidelity parser.
Summary:
The FFP uses a two-pass approach to producing errors. In the initial parsing pass, errors are reported in situations where the parser encounters something unexpected and must attempt to recover back to a known state. The first pass accepts many syntactically illegal programs, in the interests of (1) keeping the parser simpler, and (2) putting error detection code into one place. The second pass then looks for additional errors in the parse tree.
The APIs to get at the error information were confusing and weak. I've created three entrypoints to the full_fidelity_parser_errors module.
The first gives minimal error information. If there are first-pass errors, it gives them, suppressing what it thinks might be "cascading" errors. (Like "missing expression" immediately followed by "missing semicolon" at the same location. If there are no first-pass errors then it gives second pass errors.
The second gives typical error information; it gives first and second pass errors, suppressing cascading errors.
The third gives all the errors deduced by both passes.
Note that this change also has the nice property that errors are now always reported sorted by source-code order.
Reviewed By: oulgen
Differential Revision: D5797899
fbshipit-source-id: 6d29cd94a58de69277541ad8664ea4f389288b8e
Summary:
The FFP uses a two-pass approach to producing errors. In the initial parsing pass, errors are reported in situations where the parser encounters something unexpected and must attempt to recover back to a known state. The first pass accepts many syntactically illegal programs, in the interests of (1) keeping the parser simpler, and (2) putting error detection code into one place. The second pass then looks for additional errors in the parse tree.
The APIs to get at the error information were confusing and weak. I've created three entrypoints to the full_fidelity_parser_errors module.
The first gives minimal error information. If there are first-pass errors, it gives them, suppressing what it thinks might be "cascading" errors. (Like "missing expression" immediately followed by "missing semicolon" at the same location. If there are no first-pass errors then it gives second pass errors.
The second gives typical error information; it gives first and second pass errors, suppressing cascading errors.
The third gives all the errors deduced by both passes.
Note that this change also has the nice property that errors are now always reported sorted by source-code order.
Reviewed By: oulgen
Differential Revision: D5797899
fbshipit-source-id: 6d29cd94a58de69277541ad8664ea4f389288b8e