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

Peter Wang novalazy at gmail.com
Mon Jun 27 12:11:53 AEST 2022


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


More information about the reviews mailing list