[m-rev.] for review: search authorizations

Julien Fischer jfischer at opturion.com
Sat Nov 9 01:51:25 AEDT 2024


On Fri, 8 Nov 2024 at 06:18, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:

> Check what files can be searched for where ...
>
> ... (mostly) in one place.
>
> compiler/file_names.m:
>     Change the module_name_to_search_file_name predicate to
>
>     - take as input a specification of where the caller intends to search for
>       the file name returned by this predicate (the new search_which_dirs
>       input argument),
>
>     - use insts to check, at compile time, whether this specification
>       is compatible with the extention of the file (by intentionally causing

s/extention/extension/

>       the call to have a mode error if they are not compatible),
>
>     - if they are compatible, return a "search authorization" that contains
>       the information in the search_which_dirs argument in a form that
>       should be known *only* to file_names.m (which issues the authorization)
>       and find_module.m (which acts on such authorizations).
>
>     To make the above possible, move the search_which_dirs type here
>     from find_module.m, move many insts on the ext type here from several
>     other modules, and add some new insts on that type.
>
>     Improve documentation.
>
> compiler/find_module.m:
>     Delete the search_which_dirs type that this diff moves to file_names.m.
>     Add in its place the search_auth_dirs type, which represents search
>     authorizations. Make all predicates in this module take search
>     authorizations instead of search specifications as inputs. The difference
>     is that only the module_name_to_search_file_name predicate in
>     file_names.m, and a few functions in this module, generate
>     search authorization that involve references to the various options

s/authorization/authorizations/

>     containing lists of directory names.
>
> compiler/make.file_names.m:
>     Replace predicates that take a maybe_for_search argument with two
>     predicates each, one for not for search and one for search. This is
>     because the for search versions now take two extra arguments:
>     a search_which_dirs input argument and a search_auth_dirs output argument.
>
>     Factor out the common code from the resulting predicate pairs
>     where this is worth while.
>
>     Improve documentation.
>
> compiler/make.timestamp.m:
>     Replace predicates that take a maybe_for_search argument with two
>     predicates each, one for not for search and one for search. This is
>     because the for search versions and the not_for_search versions
>     now call different predicates, and two separate predicates ends up
>     being less code that tests around all the calls.
>
>     Factor out the common code from the resulting predicate pairs
>     where this is worth while.
>
>     Delete the code that specifies the default list of directories
>     in which to search for files with given extensions, since it is now
>     in file_names.m (in a modified form).

...

> diff --git a/compiler/file_names.m b/compiler/file_names.m
> index fd5dcd4dc..f671b5a8a 100644
> --- a/compiler/file_names.m
> +++ b/compiler/file_names.m

...

> @@ -585,29 +676,100 @@

...

> +%---------------------%
> +
> +    % module_name_to_search_file_name(Globals, From, Ext, ModuleName,
> +    %   SearchWhichDirs, SearchAuthDirs,
> +    %   FullFileNameLegacy, FullFileNameProposed):
> +    %
> +    % This predicate is a version of module_name_to_file_name whose job is
> +    % to return a file name (relative path) that we should *search for*
> +    % in a given list of directories, rather than the file name where the
> +    % Ext file for ModuleName definitely *should be*. This is why you should
> +    % use module_name_to_file_name if you want the file name that you should
> +    % write the file's contents to, or the file name you want to delete
> +    % as part of the "clean" or "realclean" mmake or mmc --make targets.
> +    % You should use this predicate if you want to read a file that may be
> +    % in a different source directory in a workspace, or in an installed
> +    % library.
> +    %
> +    % There are no variants with _return_dirs or _create_dirs suffixes,
> +    % because there is no point in creating the directories you are trying
> +    % to search; if you have to create a directory, it won't contain the file
>      % you are looking for.
>      %
> -    % With `--use-grade-subdirs', the current directory's `.mih' files are in
> -    % `Mercury/<grade>/<arch>/Mercury/mihs', and those for installed libraries
> -    % are in `<prefix>/lib/mercury/lib/<grade>/<arch>/inc/Mercury/mihs'.
> +    % The SearchWhichDirs argument should specify the list of directories
> +    % you want to search for the file name returned by this predicate.
> +    % There are rules about which extensions can be searched for in what
> +    % list of directories, because it does not make sense to e.g. search for
> +    % files with extensions other than .init in the directories specified
> +    % by the --init-file-directories option. The modes of this predicate
> +    % check that the insts (and therefore the values) of Ext and
> +    % SearchWhichDirs are compatible; if they are not compatible,
> +    % the call will get an intentional mode error.
>      %
> -    % handle_options.m sets up the `--c-include-directory' options so that
> -    % the name `<module>.mih' should be used in a context which requires
> -    % searching for the `.mih files, for example in a C file.
> +    % If the values of Ext and SearchWhichDirs *are* compatible, this
> +    % predicate will return in SearchAuthDirs as "search authorization".

s/as/a/

> +    % All the predicates in find_module.m that do the searches for the
> +    % returned filenames insist on their callers providing them with one.
>      %
> -    % module_name_to_file_name would return
> -    % `Mercury/<grade>/<arch>/Mercury/mihs/<module>.mihs',
> -    % which would be used when writing or removing the `.mih' file.
> -    %

That looks ok otherwise.

Julien.


More information about the reviews mailing list