Files
mercury/tests/hard_coded
Zoltan Somogyi ca7385d2c7 Generate better diagnostics for parentheses mismatches.
When you have an unclosed (, [ or { in a clause, the diagnostic
you got did not tell you

- where the unclosed parenthesis was,
- which kind of parenthesis it was.

Fix this by including both pieces of information in the diagnostic.

Likewise, print more useful info for mixed-up parentheses,
such as [(]).

library/mercury_term_parser.m:
    When consuming a (, [ or { token, push it and its context on a stack.
    When consuming a ), ] or } token, pop off the top item from this stack,
    and generate a diagnostic if the close token does not match it.
    The one exception from this pushing and pulling is for code that
    handles the case where the open is followed immediately by
    the matching close, such as when parsing [] or {}.

    Print the contents of the stack also when getting to either
    the end of the term, or the end of the input, with a nonempty stack.

    Maintaining this stack has a small performance cost, but I expect
    it to be negligible, especially compared to the usefulness
    of the new detail in diagnostics,

    Completely rework the error handling parts of this module.
    The main changes are the following.

    First, the old code used to include *part* of the intended message
    in the pr_error structures it created, with a "Syntax error: "
    prefix being added later. Since this makes it hard to ensure
    that the error messages follow the rules of English, change this
    to generate each error message all at once.

    Second, the old code included the list of the remaining tokens
    in each pr_error structure. This was overkill, because the only part
    of this list that was used was the id and the context of the
    first token in the list. Apart from being inelegant, the main flaw
    of this approach was that in the case of premature end-of-file
    errors, the only token list available was token_nil, which
    of course contains neither a token nor its context. The old code
    compensated for it later by using the context of the *first* token
    of the whole term being parsed, which is ... less than useful.
    (The missing token is trivially replaced by "end-of-file".)

    The new code replaces the token list with the context, if it
    is available; if it is not, then later we compute the context
    of the last token in the whole token list. The new code
    does not return the token itself; instead, it includes
    its string version in the generated error message where appropriate.

    Third, as mentioned above, we now include info about unbalanced
    (), [] and {} pairs in diagnostics, as extra sentences.
    (These extra sentences are preceded by \n characters;
    see the change to parse_module.m below.)

    Fifth, to make the above possible without adding unnecesary
    complications, the diagnostic texts this module generates
    now always include the period at the ends of sentences:
    they are not added by the compiler.

    Fourth, we now consistently use "Syntax error at token abc:
    expected def, fgh, or xyz" phraseology.

library/mercury_term_lexer.m:
    Stop requiring the customers of this module to handle

    - integer_dot tokens, which are needed only by, and are
      an implementation detail of, the get_* family of predicates, and

    - eof tokens, which the lexer also never returns, converting each one
      into the end of its token list instead.

    The fact that the lexer never returned integer_dot tokens was
    documented, but the fact that it never returned eof tokens was not.

    The reason for this change was simply that I did not want to write
    two pieces of code to handle the out-of-input case in each affected
    spot in the parser: once for an eof token, and once for token_nil.

library/stack.m:
    Add a utility function needed by new code in mercury_term_parser.m.

compiler/parse_module.m:
    Stop adding a period at the ends of error messages generated by
    mercury_term_parser.m; mercury_term_parser.m now adds those itself.
    Do post-process those messages by turning any \n characters in them
    into nl format_pieces.

NEWS.md:
    Announce the change in mercury_term_lexer.m, and the
    new function in stack.m.

library/io.text_read.m:
    Unrelated bug fix, for which I discovered the need while
    working on the other library files: add a missing foreign import.

tests/invalid_nodepend/unbalanced.{m,err_exp}:
    A new test case to check the updated diagnostics.

tests/invalid_nodepend/Mmakefile:
    Enable the new test case.

tests/hard_coded/parse_number_from_string.exp:
tests/invalid_nodepend/impl_def_literal_syntax.err_exp:
tests/invalid_nodepend/invalid_binary_literal.err_exp:
tests/invalid_nodepend/invalid_float_literal.err_exp:
tests/invalid_nodepend/invalid_hex_literal.err_exp:
tests/invalid_nodepend/invalid_octal_literal.err_exp:
tests/invalid_nodepend/null_char.err_exp:
tests/invalid_nodepend/typeclass_test_1.err_exp:
tests/invalid_nodepend/unicode_1.err_exp:
tests/invalid_nodepend/unicode_2.err_exp:
tests/invalid_purity/purity_nonsense_2.err_exp:
    Expect the updated diagnostics.
2025-07-30 01:37:28 +02:00
..
2023-07-01 02:25:53 +10:00
2021-11-27 02:50:29 +11:00
2021-11-27 02:50:29 +11:00
2022-02-10 09:47:41 +11:00
2023-01-11 11:04:26 +11:00
2022-03-08 06:01:21 +11:00
2022-03-08 06:01:21 +11:00
2022-05-04 09:14:47 +10:00
2023-07-22 23:24:54 +10:00
2022-05-04 09:14:47 +10:00
2022-02-10 09:47:41 +11:00
2022-03-08 06:01:21 +11:00
2022-05-04 09:14:47 +10:00
2023-02-03 19:30:53 +11:00
2022-11-12 12:53:07 +11:00
2022-11-12 12:53:07 +11:00
2023-05-02 02:22:46 +10:00
2022-05-26 16:55:03 +10:00
2025-01-02 15:36:48 +11:00
2022-03-05 15:14:27 +11:00
2022-05-04 09:14:47 +10:00