[m-rev.] for post-commit review: diagnose bad partial application

[Julien Fischer]

On Sun, 5 Jan 2025 at 00:24, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> Diagnose bad partial pred/func application.
>
> compiler/typecheck_error_undef.m:
>     When reporting an undefined name/arity pair, if the name happens
>     to be name of some functions and/or predicates which all have
>     different arities, add a sentence to the diagnostic to report this fact.
>     (Normally this happens only when the erroneous code provides
>     *too many* arguments, because if it does not, then the typechecker
>     would know that the code can be read as constructing a closure, and
>     would instead report errors for the arguments that have the wrong type.)
>
>     Don't color a closing parenthesis whose open parenthesis
>     is not colored.
>
>     Fix an old bug that we have no test case for: add the missing
>     initial part of the diagnostic for bugs that report undefined
>     *non*-user-defined function symbols. There shouldn't be any such
>     errors, but the types permit it ...
>
> tests/invalid/wrong_arity_function.{m,err_exp}:
>     Extend this test case to test diagnostic extension described above.
>
> tests/invalid/coerce_syntax.err_exp:
>     Expect the color change.

...

> diff --git a/compiler/typecheck_error_undef.m b/compiler/typecheck_error_undef.m
> index 6cf86c578..850527b3f 100644
> --- a/compiler/typecheck_error_undef.m
> +++ b/compiler/typecheck_error_undef.m
> @@ -708,20 +708,31 @@ report_error_undef_cons_std(ClauseContext, Context, InitComp, ConsErrors,
>
>      ( if ConsId = du_data_ctor(DuCtor) then
>          DuCtor = du_ctor(SymName, Arity, _),
> +        return_cons_arities(ConsTable, SymName, ConsArities),
> +        predicate_table_lookup_sym(PredicateTable, may_be_partially_qualified,
> +            SymName, PredIds),
> +        return_pred_func_arities(ModuleInfo, PredIds,
> +            [], PredArities, [], FuncArities),
> +        % A program can refer to functions both
> +        %
> +        % - by calling them, which requires their full list of arguments, and
> +        % - by constructing closures from them, which requires any initial
> +        %   subsequence of their full argument list.
> +        %
> +        % For a function with N arguments, the first requires N args in the
> +        % call, while the second is ok any in number between 0 and N.

s/any in/with any/

That looks fine otherwise.

Julien.