[m-rev.] for post-commit review: fix some debug grade test failures

[Peter Wang]

On Sun, 26 Jun 2022 10:09:25 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> Fix some test failures in debug grades.

> diff --git a/browser/declarative_oracle.m b/browser/declarative_oracle.m
> index 30abb038e..8db3cf676 100644
> --- a/browser/declarative_oracle.m
> +++ b/browser/declarative_oracle.m
> @@ -460,9 +460,38 @@ trusted(ProcLayout, Oracle) :-
>          (
>              bimap.search(Trusted, trusted_standard_library, _),
>              (
> -                Module = qualified(_, ModuleNameStr)
> -            ;
>                  Module = unqualified(ModuleNameStr)
> +            ;
> +                Module = qualified(ParentModule, SubModuleNameStr),
> +                (
> +                    ParentModule = unqualified(ParentModuleNameStr),
> +                    ModuleNameStr = ParentModuleNameStr ++ "." ++
> +                        SubModuleNameStr
> +                ;
> +                    ParentModule = qualified(GrandParentModule,
> +                        ParentModuleNameStr),
> +                    (
> +                        GrandParentModule =
> +                            unqualified(GrandParentModuleNameStr),
> +                        ModuleNameStr = GrandParentModuleNameStr ++ "." ++
> +                            ParentModuleNameStr ++ "." ++ SubModuleNameStr
> +                    ;
> +                        GrandParentModule = qualified(_, _),
> +                        fail
> +                        % Aborting would be preferable if the user is a Mercury
> +                        % developer, because it would alert us to the need
> +                        % to update this code. However, for ordinary users,
> +                        % that would be a hard violation of the law of least
> +                        % astonishment. The result of simply failing here
> +                        % will be that predicates in the modules affected
> +                        % will be treated as if they were not trusted. That is
> +                        % also a violation of that same law, but at least
> +                        % it lets the user proceed with his/her immediate task.
> +                        %
> +                        % unexpected($pred,
> +                        %     "unexpectedly deeply nested stdlib module name")
> +                    )
> +                )
>              ),
>              mercury_std_library_module(ModuleNameStr)
>          ;

Ok. This seems rather inefficient whenever 'trusted' is called for a
procedure that lives in a sub-module. Any idea if it makes a big
difference? It should be better to add each standard library module to
the trust database upfront (obviously). On the other hand, the code
doesn't look very optimised anyway.

Peter