[m-rev.] for possible post-commit review: standard order for interface file contents

Julien Fischer jfischer at opturion.com
Thu Aug 13 13:40:30 AEST 2015


Hi Zoltan,

On Thu, 13 Aug 2015, Zoltan Somogyi wrote:

> This resolves an XXX ITEM_LIST, and should further reduce
> unnecessary recompilations.

diff --git a/compiler/write_module_interface_files.m b/compiler/write_module_interface_files.m
index 253cda4..77ddc92 100644
--- a/compiler/write_module_interface_files.m
+++ b/compiler/write_module_interface_files.m
@@ -1767,265 +1757,320 @@ filter_items_for_import_needs([Item | Items], NeedForeignImports,
      filter_items_for_import_needs(Items, NeedForeignImports, !ItemsCord).

...


+    % We should be able to just sort the includes, avails and items
+    % in the parse tree. The includes and avails we *can* sort, but we cannot
+    % sort the items, because the code that adds items to the parse tree
+    % (in make_hlds_passes.m) requires that e.g. the predicate declaration
+    % for a predicate precede any mode declaration for that predicate.
+    % The order we generate puts items in this order:
      %
-    % This predicate works by finding a chunk of items which should in most
-    % cases (but unfortunately not all cases) be all the exported items,
-    % and put them in a standard order, with import_module and use_module items
-    % first in lexical order, then type, inst and mode definitions, again
-    % in lexical order, then pred and predmode declarations, in lexical order
-    % by sym_name, and finally all other items in the chunk. The chunk consists
-    % of the initial prefix of items for which this reordering is safe.
-    % The chunk will then be followed by the ordered versions of later chunks,
-    % if any.
+    % - All type definitions.
      %
-:- pred order_items(list(item)::in, list(item)::out) is det.
+    % - All inst definitions (may refer to refer to types).
+    %
+    % - All mode definitions (may refer to types and insts).
+    %
+    % - All pred and mode declarations in sym_name_and_arity order,
+    %   and with all pred declarations for a given sym_name_and_arity preceding
+    %   all mode declarations for that sym_name_and_arity. If there is a pred
+    %   declaration for both a predicate and a function for the same
+    %   sym_name_and_arity (which can happen, and does happen reasonably often)
+    %   the resulting order is somewhat awkward, but since mode declarations
+    %   contains only a maybe(pred_or_func), not a definite pred_or_func,
+    %   we cannot easily do any better. We preserve the order of mode
+    %   declarations for a given sym_name_and_arity, since these matter.
+    %
+    %   The pred and mode declarations may of course refer to types,
+    %   insts and modes.

For the sake of completeness, the pred declaration could also refer to
typeclasses; not that it will affect the ordering.

The change looks fine.

Cheers,
Julien



More information about the reviews mailing list