[m-rev.] for post-commit review: --also-output-module-order

[Peter Wang]

On Fri, 29 Aug 2025 17:15:06 +0200 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> This implements what we discussed around aug 19.
> For review by Peter, since much of it is his suggestion.
> 
> Zoltan.

> diff --git a/tests/warnings/help_text.err_exp b/tests/warnings/help_text.err_exp
> index 0cf741457..d958c7a47 100644
> --- a/tests/warnings/help_text.err_exp
> +++ b/tests/warnings/help_text.err_exp
> @@ -2355,15 +2355,37 @@ Intermodule optimization
>          are already built, e.g. those for the standard library, but do not
>          build any others.
>  
> +    --also-output-module-order
>      --generate-module-order
> -        Output the strongly connected components of the module dependency graph
> -        in top-down order to `<module>.order'. Effective only if
> -        `--generate-dependencies' is also specified.
> +        If `--generate-dependencies' is also specified, then output the
> +        strongly connected components of the module dependency graph in
> +        top-down order to `<module>.module_order'. If `--generate-dependencies'
> +        is not specified, then this option does nothing.)
>  
>      PRIVATE OPTION
>      --trans-opt-deps-spec <filename>
>      --no-trans-opt-deps-spec
> -        Specify a file to remove edges from the trans-opt dependency graph.
> +        When constructing e.g. `<module_a>..trans_opt', the compiler is allowed

I've fixed the double dot.

> +        to read the `.trans_opt' files of only the modules that follow module_a
> +        in a designated module order. The purpose of this restriction is the
> +        prevention of circular dependencies between `.trans_opt' files. The
> +        compiler normally decides this module order by constructing the
> +        dependency graph between modules, computing its strongly connected
> +        components (SCCs), and flattening those components in a top-down-order,
> +        breaking the circular dependencies inside each SCC effectively
> +        randomly. If this option is specified, and the named file contains a
> +        properly formatted specification of a set of directed edges between
> +        pairs of modules, then the compiler will remove those edges from the
> +        dependency graph before computing the SCCs.

It's not exactly what the file contains, but close enough for now.

Peter