[m-rev.] diff: phasing problem in building the HLDS

[Julien Fischer]

On Tue, 15 Jul 2025 at 01:01, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:

> Fix a phasing problem in building the HLDS.

...

> diff --git a/compiler/check_field_access_functions.m b/compiler/check_field_access_functions.m
> index c9b615b86..c0d42e017 100644
> --- a/compiler/check_field_access_functions.m
> +++ b/compiler/check_field_access_functions.m

> diff --git a/compiler/make_hlds_passes.m b/compiler/make_hlds_passes.m
> index 4da94d0fc..4ece530f2 100644
> --- a/compiler/make_hlds_passes.m
> +++ b/compiler/make_hlds_passes.m
> @@ -324,6 +324,61 @@ parse_tree_to_hlds(ProgressStream, AugCompUnit, Globals, DumpBaseFileName,
>      check_mode_defns(!.ModuleInfo, ModeDefns,
>          !FoundInvalidInstOrMode, !Specs),
>
> +    % We want to invoke post-process the type table, after all the type

   on the type table?

> +    % definitions have been added to it, to do several tasks. These include
> +    %
> +    % 1 checking subtype definitions (to check compatibility
> +    %   with their declared supertype),

Why not just

     1. checking compatibility of subtype definitions with their
declared supertype
?

> +    % 2 checking whether foreign types exist for the current target language,
> +    %
> +    % 3 adding all data constructors to the cons_table,
> +    %
> +    % 4 adding all named fields to the ctor_field_table,
> +    %
> +    % 5 checking whether the predicates named as unify and compare predicates
> +    %   exist. and have the appropriate signature for their role.

Delete the stray full stop there.

> +    % The code of add_du_ctors_check_subtype_check_foreign_type does 1 to 4,
> +    % but not 5, which is why we don't have to do this after adding all
> +    % predicate declarations to the HLDS. However, it does matter
> +    % when we do it compared to adding *mode* declarations; specifially,

s/specifially/specifically.

> +    % we need to do it *before* processing mode declarations.
> +    %
> +    % This is because adding mode declarations to the HLDS may require
> +    % adding implicit pred declarations. With our current setup, this requires
> +    % checking the "predicates" that happen to be functions whether they are
> +    % field access functions.

    *for* whether they are

> This in turn requires access to a completed
> +    % ctor_field table. (The reason for this is that in the absence of
> +    % an actual pred_decl, the call to check_preds_if_field_access_function
> +    % below won't process these functions.)
> +    %
> +    % If we ever change check_preds_if_field_access_function to process
> +    % all local "predicates" and not just the ones with explicit pred_decls,
> +    % we could move this block of code after the addition of all pred_decls
> +    % (explicit and implicit) to the HLDS, and have it do task 5 as well as
> +    % tasks 1-4. This should allow us to generate better error messages.
> +    % (Currently, we discover any such errors when we type and mode check
> +    % the automatically created unify and compare predicates, whose bodies
> +    % call the user-specified predicate names.)
> +    (
> +        !.FoundInvalidType = did_not_find_invalid_type,
> +        % Add constructors for du types to the HLDS, check subtype definitions,

The rest looks fine.

Julien.