[m-rev.] (no subject)

Julien Fischer jfischer at opturion.com
Sat Apr 23 12:58:53 AEST 2022


On Sat, 23 Apr 2022, Zoltan Somogyi wrote:

> Separate fatal and nonfatal module reading errors, ...
> 
> ... and bundle sets of error kinds and their associated lists of error_specs
> into a single structure.

...

> diff --git a/compiler/parse_error.m b/compiler/parse_error.m
> index ecd5800ef..c8f998ae8 100644
> --- a/compiler/parse_error.m
> +++ b/compiler/parse_error.m
> @@ -9,17 +9,60 @@
>  :- module parse_tree.parse_error.
>  :- interface.
> 
> +:- import_module parse_tree.error_util.
> +
> +:- import_module list.
>  :- import_module set.
> 
> -    % This type represents the kinds of errors that can happen
> -    % when we (attempt to) read in a Mercury module (which will be
> -    % either a source file, or an interface file).
> +    % 1. We obviously cannot process the module if we could not read it.
> +    %
> +    % 2. If the module contains some bad ":- module" declarations, then
> +    %    the identity of the module that contains any items following
> +    %    such declarations will be in doubt. The compiler can guess the
> +    %    identity of the module intended by the programmer only by chance,
> +    %    and any mistake will typically lead to an avalanche of misleading
> +    %    errors.
> +    %
> +    % 3. If the module contains some bad ":- end_module" declarations,
> +    %    then the same is true for any items following those declarations.
> +    %
> +    % Items follow most ":- module" declarations, but not most ":- end_module"
> +    % declarations, and if no items follow a bad ":- end_module" declaration,
> +    % then the badness of the declaration has no further consequences.
> +    % It would therefore be worthwhile making a distinction between bad
> +    % ":- end_module" declarations that have items following them, and those
> +    % that don't. Unfortunately, since each item is processed independently,
> +    % that is not trivial to do.
>      %
> -:- type read_module_error
> -    --->    rme_could_not_open_file
> +:- type fatal_read_module_error
> +    --->    frme_could_not_open_file
>              % We could not open the specified file.
> 
> -    ;       rme_unexpected_module_name
> +    ;       frme_could_not_read_file
> +            % We could open the specified file, but could not read its
> +            % contents.
> +
> +    ;       frme_bad_submodule_start
> +            % We encountered a declaration for the starting of a submodule,

s/starting/start/

> +            % but the name of the new submodule is not that can be immediately
> +            % nested inside the current module.
> +            % NOTE: This error can happen only for SUBmodules of the main

Did you mean to capitalize SUBmodules like that?  (If it was for empahsis, I
suggest capitlizing the entire word.)

> +            % module in the file. For the main module itself, we would generate
> +            % the rme_unexpected_module_name error.
> +
> +    ;       frme_bad_module_end.
> +            % We encountered a declaration for the ending of a module,

s/ending/end/

> +            % but the name of the ended module is not the name of the
> +            % until-then-current module.
> +            % NOTE: This error can happen both for the main module of the
> +            % file and for its submodules.

The rest looks fine.

Julien.


More information about the reviews mailing list