From zoltan.somogyi at runbox.com Sat May 3 17:46:00 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 03 May 2025 17:46:00 +1000 (AEST) Subject: [m-rev.] for post-commit review: more specific warnings about unresolved polymorphism Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.urp Type: application/octet-stream Size: 1391 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.urp Type: application/octet-stream Size: 52050 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sat May 3 18:05:00 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 03 May 2025 18:05:00 +1000 (AEST) Subject: [m-rev.] for review: delete some redundant checks for NULL Message-ID: I asked boehm_gc's maintainer which allocating macros and functions are guaranteed never to return NULL unless the out-of-memory handler itself returns NULL, and they include all the ones we use. (I created a pull request to make this explicit in boehm_gc's upstream documentation of all the relevant macros/functions; that request was accepted.) So this diff deletes the NULL checks that we now know are redundant. For review by anyone. Since the deleted tests were extremely easy for branch predictors to handle, I don't expect a significant speedup. However, next I intend to look into optimizing away calls to MR_GC_malloc, MR_GC_malloc_atomic et al if we using boehm gc; since their bodies now contain nothing but a call to the associated boehm allocation macro, calls to them can be replaced by a direct invocation of that macro. This should yield a bigger speedup, though I don't know what it will do to code size. BTW, does anyone happen to know why *initializing* conservative gc handles both MR_BOEHM_GC and MR_HGC, but the alliocation functions themselves do not handle MR_HGC, and assume, incorrectly, that MR_CONSERVATIVE_GC can mean only MR_BOEHM_GC? Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.null Type: application/octet-stream Size: 619 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.null Type: application/octet-stream Size: 6394 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sun May 4 04:35:41 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 04 May 2025 04:35:41 +1000 (AEST) Subject: [m-rev.] for post-commit review: don't warn about redundant imports when making .int files Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.ri Type: application/octet-stream Size: 867 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.ri Type: application/octet-stream Size: 5128 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sun May 4 11:14:30 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 04 May 2025 11:14:30 +1000 (AEST) Subject: [m-rev.] diff: mark_trace_goals.m Message-ID: This does not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.mtg Type: application/octet-stream Size: 278 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.mtg Type: application/octet-stream Size: 17083 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 5 07:58:45 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 05 May 2025 07:58:45 +1000 (AEST) Subject: [m-rev.] for possible objection: add ft=make, and copyright years Message-ID: The only thing worth looking at is the addition of copyright years by the Mercury team for a couple of files that did not have them. I think they were missing because of oversight, but someone may know of a substantive reason. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.ftm Type: application/octet-stream Size: 149 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.ftm Type: application/octet-stream Size: 17587 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 5 08:08:33 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 05 May 2025 08:08:33 +1000 (AEST) Subject: [m-rev.] diff: minor style improvements in extras Message-ID: This should not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.extras Type: application/octet-stream Size: 2614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.extras Type: application/octet-stream Size: 246791 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 5 08:23:21 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 05 May 2025 08:23:21 +1000 (AEST) Subject: [m-rev.] for review: delete some redundant checks for NULL In-Reply-To: References: Message-ID: On Sat, 03 May 2025 18:05:00 +1000 (AEST), "Zoltan Somogyi" wrote: > I asked boehm_gc's maintainer which allocating macros and functions > are guaranteed never to return NULL unless the out-of-memory handler > itself returns NULL, and they include all the ones we use. (I created a pull > request to make this explicit in boehm_gc's upstream documentation > of all the relevant macros/functions; that request was accepted.) > So this diff deletes the NULL checks that we now know are redundant. > For review by anyone. In the absence by then of either a review or a promise of one, I intend to commit this about 5pm today. Zoltan. From zoltan.somogyi at runbox.com Mon May 5 09:07:32 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 05 May 2025 09:07:32 +1000 (AEST) Subject: [m-rev.] diff: improve delay_info.m's invariant checks Message-ID: This should not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.di Type: application/octet-stream Size: 443 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.di Type: application/octet-stream Size: 12859 bytes Desc: not available URL: From jfischer at opturion.com Mon May 5 15:03:20 2025 From: jfischer at opturion.com (Julien Fischer) Date: Mon, 5 May 2025 15:03:20 +1000 Subject: [m-rev.] for post-commit review: more specific warnings about unresolved polymorphism In-Reply-To: References: Message-ID: On Sat, 3 May 2025 at 17:46, Zoltan Somogyi wrote: > > Make a warning more specific. ... > diff --git a/compiler/var_origins.m b/compiler/var_origins.m > new file mode 100644 > index 000000000..1540fc3ba > --- /dev/null > +++ b/compiler/var_origins.m > @@ -0,0 +1,809 @@ > +%---------------------------------------------------------------------------% > +% vim: ft=mercury ts=4 sw=4 et > +%---------------------------------------------------------------------------% > +% Copyright (C) 2025 The Mercury team. > +% This file may only be copied under the terms of the GNU General > +% Public License - see the file COPYING in the Mercury distribution. > +%---------------------------------------------------------------------------% > +% > +% This module provides mechanisms to > +% > +% - map each variable in a predicate to its earliest occurrence in each > +% clause of a given predicate (its origins), and > +% > +% - to map descriptions of such origins into text that can be included > +% in error messages. > +% > +% The overall intention is to improve the readability of error messages > +% such as > +% > +% Warning: unresolved polymorphism in predicate `maybe_throw_pred'/2. > +% The variable with an unbound type was: > +% `V_7': exception.exception_result(T). > +% The unbound type variable `T' will be implicitly bound to > +% the builtin type `void'. > +% > +% Each of these lines has traditionally been prefixed by the context > +% of the predicate as a whole. When the subject of the diagnostic is > +% a named variable, this does not matter, since users can look for > +% occurrences of that variable in the predicate's code. However, for > +% unnamed variables, they cannot. This is why this module provides > +% the mechanisms needed to extend the diagnostic with text such as > +% > +% `V_7' represents the term `exception(Exception)'. > +% > +% with the preceding context pinpointing the line where the unnamed > +% variable first occurs. See tests/warnings/unresolved_polymorphism_anon.m. > +% > +% Because this intention is to help with error messages created during > +% type analysis, this module does not look at, or use, any part of the HLDS > +% that is meaningful during type analysis, such as instmap_deltas. I think you mean mode analysis there. ... > +:- type var_origin > + ---> var_origin_clause_head( > + % The variable's first occurrence is in the clause head. > + voch_context :: prog_context, > + > + % The number of the clause in the predicate's definition. > + % The first clause is clause #1. > + voch_clause :: uint, > + > + % The position of the variable in the clause head. > + % The first argument is argument #1. > + voch_arg_num :: uint > + ) > + ; var_origin_lambda_head( > + % The variable's first occurrence is in the head of > + % a lambda expression. > + volh_context :: prog_context, > + volh_p_or_f :: pred_or_func, > + volh_arg_num :: uint > + ) > + ; var_origin_unify_var( > + vouv_context :: prog_context, > + % The other variable that the variable mapped to this origin > + % is unified with. > + vouv_lorhs :: lhs_or_rhs > + ) > + ; var_origin_unify_func( > + vouf_context :: prog_context, > + > + % The cons_id in the unification. > + vouf_cons_id :: cons_id, > + > + % If the variable mapped to this origin is the LHS var, > + % then this lists the RHS vars. > + % If the variable mapped to this origin is one of the RHS vars, > + % then this gives its position on the RHS, as well as > + % the LHS var. > + vouf_lorhsa :: lhs_or_rhs_arg > + ) > + ; var_origin_plain_call( > + vopc_context :: prog_context, > + % The id of the callee, and the number of the argument > + % position that is occupied by the variable mapped > + % to this origin. (If that variable is only a *component* > + % of the argument, and not the whole argument, then its > + % origin will be unification introduced by the code of > + % superhomoneous.m.) > + vopc_callee :: pred_id, > + vopc_arg_num :: uint > + ) > + ; var_origin_foreign_call( > + vofc_context :: prog_context, > + % We treat foreign language calls the same way as plain calls. > + vofc_callee :: pred_id, > + vofc_arg_num :: uint > + ) > + ; var_origin_generic_call( > + vogc_context :: prog_context, > + % We treat treat language calls similarly to plain calls, > + % just with a different specification of the callee. > + vogc_callee :: generic_call, > + vogc_arg_num :: uint > + ). > + > +:- type lhs_or_rhs > + ---> lor_lhs( > + rhs_var :: prog_var > + ) > + ; lor_rhs( > + lhs_var :: prog_var > + ). > + > +:- type lhs_or_rhs_arg > + ---> lora_lhs( > + rhs_argvars :: list(prog_var) > + ) > + ; lora_rhs( > + lhs_var :: prog_var, > + rhs_arg_num :: uint > + ). > + > + % Values of this type map each variable to > + % > + % - its origin, if it has only one origin (that we have seen so far), > + % > + % - but if the variable has its origin in a (possibly nested) branched > + % control structure, it will contain its origin on each branch. > + % Note that multiple clauses, being equivalent to multiple disjuncts, > + % count as branches of a branched control structure. > +:- type var_origins_map == map(prog_var, set(var_origin)). > + > + % compute_var_origins_in_pred(CollectPred, PredInfo0, OriginsMap, !Acc): > + % > + % Given a predicate, construct and return OriginsMap, which will map > + % each variable in its clauses to its set of origins. > + % > + % Note that one kind of goal, negations, introduce scopes that 'forget' > + % origins. This is because if a variable is generated in a negated goal, > + % it cannot be referred to from outside the negation. Therefore any > + % additions to OriginsMap inside a negated goal will be effectivel s/effectivel/effectively/ > + % forgotten when the traversal leaves the negation. > + % > + % This is why instead of letting our caller post-process OriginsMap, > + % we allow it to process each addition to OriginsMap as it is made. > + % The traversal will call CollectPred after each such addition, > + % passing it both the already-updated OriginsMap, and the pair of > + % that was just added. > + % > +:- pred compute_var_origins_in_pred( > + record_var_origin(T)::in(record_var_origin), > + pred_info::in, var_origins_map::out, T::in, T::out) is det. ... > +:- pred update_var_origin(record_var_origin(T)::in(record_var_origin), > + prog_var::in, var_origin::in, > + var_origins_map::in, var_origins_map::out, T::in, T::out) is det. > + > +update_var_origin(CollectPred, Var, VarOrigin, !OriginsMap, !Acc) :- > + ( if map.search(!.OriginsMap, Var, _VarOriginsCord0) then > + % set.insert(VarOrigin, VarOriginsCord0, VarOriginsCord), > + % map.det_update(Var, VarOriginsCord, !OriginsMap) > + % ZZZ What's the ZZZ for? > + true > + else > + VarOriginsCord = set.make_singleton_set(VarOrigin), > + map.det_insert(Var, VarOriginsCord, !OriginsMap), > + CollectPred(!.OriginsMap, Var, VarOrigin, !Acc) > + ). ... > diff --git a/tests/warnings/unresolved_polymorphism_anon.m b/tests/warnings/unresolved_polymorphism_anon.m > new file mode 100644 > index 000000000..a45bf4ff7 > --- /dev/null > +++ b/tests/warnings/unresolved_polymorphism_anon.m > @@ -0,0 +1,68 @@ > +%---------------------------------------------------------------------------% > +% vim: ts=4 sw=4 et ft=mercury > +%---------------------------------------------------------------------------% > +% > +% When the compiler generates a warning about unresolved polymorphism, > +% sometimes the variable being complained about is an anonymous variable. > +% Since by definition users cannot see such variables in their programs, > +% the error message does not give them any guidance of what they can change > +% to make the warning go away. > +% > +% This test case tests the operation of the code in the compiler > +% (var_origins.m) that generates messages to tell users > +% > +% - both the context of the first occurrence of the anonymous variable > +% as a filename/linenumber pair, > +% > +% - and how the variable fits in with the code in which it occurs, > +% which should help focus their attention on the affected *part* of that > +% line. > +% > +% This test case is a cut-down form of the code that motivated the change > +% being tested here: an unresolved polymorphism in extras/odbc/odbc.m. > +% > +% XXX It would be nice to test variable origins other than just "this variable > +% represents a term constructed here". We can of coyrse add test cases s/coyrse/course/ > +% for such situations as we come across them. The rest looks fine. Julien. From jfischer at opturion.com Mon May 5 15:06:35 2025 From: jfischer at opturion.com (Julien Fischer) Date: Mon, 5 May 2025 15:06:35 +1000 Subject: [m-rev.] for post-commit review: don't warn about redundant imports when making .int files In-Reply-To: References: Message-ID: On Sun, 4 May 2025 at 04:35, Zoltan Somogyi wrote: > Report redundant imports only when generating code. > > compiler/convert_import_use.m: > Make the warnings we generate for imports that are redundant in > various ways all conditional on a flag that is explicitly switched off > when we generate .int files. The warnings served a purpose when they > signalled to the user that they needed to delete the redundant imports > if they wanted to avoid getting the same warning for every module that > depended on the bad module's .int file. Since the process for creating > .int files has automatically filtered out the redundant imports for > years now, this behavior is no longer needed. > > tests/invalid_make_int/redundant_import.{m,int_err_exp}: > A new test case for the suppression of redundant import warnings > when making .int files. > > tests/invalid_make_int/Mmakefile: > Enable the new test case. That's fine. Julien. From zoltan.somogyi at runbox.com Mon May 5 15:13:04 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 05 May 2025 15:13:04 +1000 (AEST) Subject: [m-rev.] for post-commit review: more specific warnings about unresolved polymorphism In-Reply-To: References: Message-ID: On Mon, 5 May 2025 15:03:20 +1000, Julien Fischer wrote: > On Sat, 3 May 2025 at 17:46, Zoltan Somogyi wrote: > > +% Because this intention is to help with error messages created during > > +% type analysis, this module does not look at, or use, any part of the HLDS > > +% that is meaningful during type analysis, such as instmap_deltas. > > I think you mean mode analysis there. No, I meant type analysis, but there is a NOT missing from before "meaningful". Fixed. > > +:- pred update_var_origin(record_var_origin(T)::in(record_var_origin), > > + prog_var::in, var_origin::in, > > + var_origins_map::in, var_origins_map::out, T::in, T::out) is det. > > + > > +update_var_origin(CollectPred, Var, VarOrigin, !OriginsMap, !Acc) :- > > + ( if map.search(!.OriginsMap, Var, _VarOriginsCord0) then > > + % set.insert(VarOrigin, VarOriginsCord0, VarOriginsCord), > > + % map.det_update(Var, VarOriginsCord, !OriginsMap) > > + % ZZZ > > > What's the ZZZ for? To remind me to delete the previous two lines, if, as expected, they turned out not to be needed. It didn't work :-( I followed all your other suggestions. Thanks for the review. Zoltan. From jfischer at opturion.com Mon May 5 15:27:46 2025 From: jfischer at opturion.com (Julien Fischer) Date: Mon, 5 May 2025 15:27:46 +1000 Subject: [m-rev.] for review: delete some redundant checks for NULL In-Reply-To: References: Message-ID: On Sat, 3 May 2025 at 18:05, Zoltan Somogyi wrote: > > I asked boehm_gc's maintainer which allocating macros and functions > are guaranteed never to return NULL unless the out-of-memory handler > itself returns NULL, and they include all the ones we use. (I created a pull > request to make this explicit in boehm_gc's upstream documentation > of all the relevant macros/functions; that request was accepted.) > So this diff deletes the NULL checks that we now know are redundant. > For review by anyone. > > Since the deleted tests were extremely easy for branch predictors to handle, > I don't expect a significant speedup. However, next I intend to look into > optimizing away calls to MR_GC_malloc, MR_GC_malloc_atomic et al > if we using boehm gc; since their bodies now contain nothing but > a call to the associated boehm allocation macro, calls to them can be replaced > by a direct invocation of that macro. This should yield a bigger speedup, > though I don't know what it will do to code size. > > BTW, does anyone happen to know why *initializing* conservative gc > handles both MR_BOEHM_GC and MR_HGC, but the alliocation functions > themselves do not handle MR_HGC, and assume, incorrectly, that > MR_CONSERVATIVE_GC can mean only MR_BOEHM_GC? I wouldn't read much into it - HGC (as I am sure you are aware) is highly incomplete. > Avoid redundant NULL check on Boehm alloc results. > > runtime/mercury_memory.c: > In the functions that call GC_MALLOC, GC_MALLOC_ATOMIC, > GC_MALLOC_UNCOLLECTABLE or GC_REALLOC, do not check whether > the pointers they return are NULL, since the oom (out-of-memory) > handler we specify for Boehm gc will have already checked for NULL, > and it will abort the program instead of returning NULL. > > runtime/mercury_memory.h: > Make some comments more readable. > > runtime/mercury_wrapper.c: > Document mercury_memory.c's reliance on the oom handler. > > Check for MR_BOEHM_GC explicitly, not via an inference. That's fine. Julien. From jfischer at opturion.com Mon May 5 15:52:15 2025 From: jfischer at opturion.com (Julien Fischer) Date: Mon, 5 May 2025 15:52:15 +1000 Subject: [m-rev.] for possible objection: add ft=make, and copyright years In-Reply-To: References: Message-ID: On Mon, 5 May 2025 at 07:58, Zoltan Somogyi wrote: > > The only thing worth looking at is the addition of copyright years > by the Mercury team for a couple of files that did not have them. > I think they were missing because of oversight, but someone may know > of a substantive reason. They were just an omission; I 've just pushed a change that updates a few of the copyright notices. Julien. From zoltan.somogyi at runbox.com Mon May 5 20:33:26 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 05 May 2025 20:33:26 +1000 (AEST) Subject: [m-rev.] for review: warn about moved trace goals Message-ID: For review by anyone. I would like to build on this tomorrow, so in the absence of a review by then, I intend to commit this tomorrow lunchtime, and deal with any comments post-commit. Note: the last attached file in the initial part of the output of "mmc --debug-modes moved_trace_goal.m", the part that already shows the problems mentioned in the log message, and which I would like to fix tomorrow, at least for trace goals. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.wmtg Type: application/octet-stream Size: 3172 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.wmtg Type: application/octet-stream Size: 105821 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: moved_trace_goal.debug_modes Type: application/octet-stream Size: 9895 bytes Desc: not available URL: From jfischer at opturion.com Tue May 6 09:48:52 2025 From: jfischer at opturion.com (Julien Fischer) Date: Tue, 6 May 2025 09:48:52 +1000 Subject: [m-rev.] for review: warn about moved trace goals In-Reply-To: References: Message-ID: On Mon, 5 May 2025 at 20:33, Zoltan Somogyi wrote: > Generate a warning for moved trace goals. > > compiler/mark_trace_goals.m: > When we find a trace goal that occurs at a higher line number in a file > than the line number of a goal to its left, generate a warning about the > move. > > compiler/goal_expr_to_goal.m: > When converting the parse tree's try goals to HLDS goals, we need > to add some goals to the start of code pieces that catch exceptions. > Give these goals the context of the try goal as a whole, which will be > the context of its start, rather that the context of the catching goal, > which (e.g. if it is a conjunction) may point to the *middle* of that goal. > This is needed to avoid spurious warnings from the new code in > mark_trace_goals.m when the catching goal contains a trace goal. That's fine. Julien. From zoltan.somogyi at runbox.com Tue May 6 10:26:53 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 06 May 2025 10:26:53 +1000 (AEST) Subject: [m-rev.] for post-commit review: refer to field names, not field labels Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.fn Type: application/octet-stream Size: 137 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.fn Type: application/octet-stream Size: 5357 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Tue May 6 14:24:37 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 06 May 2025 14:24:37 +1000 (AEST) Subject: [m-rev.] for post-commit review: work around the trace-goal-moving-too-far bug Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.wmtg2 Type: application/octet-stream Size: 693 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.wmtg2 Type: application/octet-stream Size: 10343 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sat May 10 12:51:08 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 10 May 2025 12:51:08 +1000 (AEST) Subject: [m-rev.] for post-commit review: report unused modules in bulk Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.ui Type: application/octet-stream Size: 1091 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.ui Type: application/octet-stream Size: 15244 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 12 21:26:35 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 12 May 2025 21:26:35 +1000 (AEST) Subject: [m-rev.] for post-commit review: delay reporting missing parent imports Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cia Type: application/octet-stream Size: 3072 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cia Type: application/octet-stream Size: 31793 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 12 21:37:59 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 12 May 2025 21:37:59 +1000 (AEST) Subject: [m-rev.] =?utf-8?q?for_post-commit_review=3A_delay_reporting_miss?= =?utf-8?q?ing_parent=09imports?= In-Reply-To: References: Message-ID: On Mon, 12 May 2025 21:26:35 +1000 (AEST), "Zoltan Somogyi" wrote: > For review by anyone. The diff, and the commit, were made without writing out my last changes to comments in prog_parse_tree.m. I have now committed them. Zoltan. From jfischer at opturion.com Wed May 14 14:16:22 2025 From: jfischer at opturion.com (Julien Fischer) Date: Wed, 14 May 2025 14:16:22 +1000 Subject: [m-rev.] for review: update README.macOS.md Message-ID: For review by anyone. ------------------------------------------ Update README.macOS.md: README.macOS.md: Mention that Apple Silicon machines are supported. Minor adjustments. Julien. diff --git a/README.macOS.md b/README.macOS.md index 3bddf361b..5f5aede2b 100644 --- a/README.macOS.md +++ b/README.macOS.md @@ -1,24 +1,25 @@ Mercury on macOS ================ -This file documents the port of Mercury to macOS / OS X / Mac OS X +This file documents the port of Mercury to macOS. (i.e. the `*-apple-darwin*` configuration). -Versions of macOS prior to 10.9 are not supported. +Versions of macOS prior to 10.9 are not supported. Both Intel and Apple Silicon +Macs are supported, although the latter has not been extensively tested. Contents -------- -* Mercury on Intel Macs +* Mercury on macOS * Note for users of Xcode 11 * Deployment Target Settings * Deep profiling on macOS -Mercury on Intel Macs ----------------------- +Mercury on macOS +---------------- -Mercury should build and install "out-of-the-box" on Intel Macs using macOS -10.9 onwards. +Mercury should build and install "out-of-the-box" on Intel and Apple Silicon +Macs using macOS 10.9 onwards. The `asm_fast*` and `reg*` grades are only available on 64-bit Intel systems and only when using GCC version 4.3 or later as the C compiler. @@ -32,10 +33,9 @@ If the `asm_fast.gc` grade is not available, and unless otherwise directed, then the `hlc.gc` grade will be used as the default grade for compiling applications. -On x86-64 machines, the default is to install 64-bit versions of the -executables and libraries in the Mercury system. On machines running versions -of macOS up to and including 10.14, users can choose to install 32-bit versions -instead by invoking Mercury's `configure` script either with the option +On machines running versions of macOS up to, and including, 10.14, users can +choose to install a 32-bit version of Mercury by invoking Mercury's `configure` +script either with the option ``` --with-cc="clang -m32" @@ -49,18 +49,18 @@ or depending on their preferred compiler. In either case, every invocation of the selected C compiler on Mercury-generated C files will specify -the `-m32` option. The reason for the limitation to 10.14 is that +the `-m32` option. The reason for the restriction to version 10.14 is that 32-bit executables are not supported at all from macOS 10.15 onwards. If, after installing Mercury, you encounter errors about missing `.mih` files, -and you have fink installed, then try removing the fink components from your -`PATH` (these usually start with `/sw`) and reinstalling. +and you have fink installed,try removing the fink components from your `PATH` +(these usually start with `/sw`) and reinstalling. Note for users of Xcode 11 -------------------------- Versions of Xcode 11 prior to 11.4 ship with a broken version of `clang` -that *cannot* be used to compile Mercury. The `configure` script will print +that *cannot* be used to compile Mercury. The `configure` script will print a warning if it detects that you are using the broken version. A discussion of this issue can be found at From zoltan.somogyi at runbox.com Wed May 14 14:26:37 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 14 May 2025 14:26:37 +1000 (AEST) Subject: [m-rev.] for review: update README.macOS.md In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:16:22 +1000, Julien Fischer wrote: > -Versions of macOS prior to 10.9 are not supported. > +Versions of macOS prior to 10.9 are not supported. Both Intel and Apple Silicon > +Macs are supported, although the latter has not been extensively tested. I would change both sentences to use the active voice, with "Mercury supports ...". > @@ -49,18 +49,18 @@ or > > depending on their preferred compiler. In either case, every invocation > of the selected C compiler on Mercury-generated C files will specify > -the `-m32` option. The reason for the limitation to 10.14 is that > +the `-m32` option. The reason for the restriction to version 10.14 is that > 32-bit executables are not supported at all from macOS 10.15 onwards. Again, switch to active voice, and say that it is *Apple* that does not support 32-bit executables on those versions. > If, after installing Mercury, you encounter errors about missing `.mih` files, > -and you have fink installed, then try removing the fink components from your > -`PATH` (these usually start with `/sw`) and reinstalling. > +and you have fink installed,try removing the fink components from your `PATH` > +(these usually start with `/sw`) and reinstalling. How can fink interfere with .mih files? If the answer is not too complex, it would be worthwhile including it here. Also, add a space the command and "try". > Note for users of Xcode 11 > -------------------------- > > Versions of Xcode 11 prior to 11.4 ship with a broken version of `clang` > -that *cannot* be used to compile Mercury. The `configure` script will print > +that *cannot* be used to compile Mercury. The `configure` script will print > a warning if it detects that you are using the broken version. The diff is otherwise fine. Zoltan. From juliensf at gmail.com Wed May 14 15:08:40 2025 From: juliensf at gmail.com (Julien Fischer) Date: Wed, 14 May 2025 15:08:40 +1000 Subject: [m-rev.] for review: update README.macOS.md In-Reply-To: References: Message-ID: On Wed, 14 May 2025 at 14:26, Zoltan Somogyi wrote: > > > On Wed, 14 May 2025 14:16:22 +1000, Julien Fischer wrote: > > -Versions of macOS prior to 10.9 are not supported. > > +Versions of macOS prior to 10.9 are not supported. Both Intel and Apple Silicon > > +Macs are supported, although the latter has not been extensively tested. > > I would change both sentences to use the active voice, with "Mercury supports ...". Done. > > @@ -49,18 +49,18 @@ or > > > > depending on their preferred compiler. In either case, every invocation > > of the selected C compiler on Mercury-generated C files will specify > > -the `-m32` option. The reason for the limitation to 10.14 is that > > +the `-m32` option. The reason for the restriction to version 10.14 is that > > 32-bit executables are not supported at all from macOS 10.15 onwards. > > Again, switch to active voice, and say that it is *Apple* that does not support > 32-bit executables on those versions. Done, I've said macOS rather than Apple. > > If, after installing Mercury, you encounter errors about missing `.mih` files, > > -and you have fink installed, then try removing the fink components from your > > -`PATH` (these usually start with `/sw`) and reinstalling. > > +and you have fink installed,try removing the fink components from your `PATH` > > +(these usually start with `/sw`) and reinstalling. > > How can fink interfere with .mih files? If the answer is not too complex, it would be > worthwhile including it here. That text is over 15 years old and was written by Ian MacLarty. In the log message, he says : I had this problem and removing fink from my PATH fixed it (though I don't know why). I don't know why either. > Also, add a space the command and "try". Done. Julien. From zoltan.somogyi at runbox.com Fri May 16 03:46:37 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 16 May 2025 03:46:37 +1000 (AEST) Subject: [m-rev.] for review: warn about unneeded initial and final state vars Message-ID: For review by anyone. I will update the user guide once the new documentation in options.m is approved. Much of the diff consists of me acting on the new warnings, so you can see how useful they are. I have not yet acted on *all* such warnings, because this diff is large enough already; that will come later. Zoltan -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.usw Type: application/octet-stream Size: 7113 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.usw.gz Type: application/x-gzip Size: 57304 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Fri May 16 19:56:02 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 16 May 2025 19:56:02 +1000 (AEST) Subject: [m-rev.] =?utf-8?q?for_review=3A_warn_about_unneeded_initial_and_?= =?utf-8?q?final_state=09vars?= In-Reply-To: References: Message-ID: On Fri, 16 May 2025 03:46:37 +1000 (AEST), "Zoltan Somogyi" wrote: > For review by anyone. In the absence of a review, I have committed the changes to options.m (with the user-visible change commented out) and handle_options.m, in order to make it possible to add the new options to Mercury.options files sooner. I would still welcome a review. Zoltan. From zoltan.somogyi at runbox.com Fri May 16 20:10:59 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 16 May 2025 20:10:59 +1000 (AEST) Subject: [m-rev.] for post-commit review: clarify a diagnostic from prepare.sh Message-ID: I would appreciate a review from someone who knows git's submodule system better than me. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.prep Type: application/octet-stream Size: 898 bytes Desc: not available URL: From jfischer at opturion.com Sun May 18 02:32:17 2025 From: jfischer at opturion.com (Julien Fischer) Date: Sun, 18 May 2025 02:32:17 +1000 Subject: [m-rev.] for review: warn about unneeded initial and final state vars In-Reply-To: References: Message-ID: On Fri, 16 May 2025 at 03:46, Zoltan Somogyi wrote: > Add options to warn about unused state vars. > > The new --warn-unneeded-initial-statevar option asks the compiler to warn about > code such as > > pred_a(!.X, ...) :- > ... code that uses !.X, but does not update it ... > > In this case, the preferred fix is to just replace all occurrences > of !.X with X. > > The new --warn-unneeded-final-statevar option asks the compiler to warn about > code such as > > pred_a(!X, ...) :- > ... code that maybe uses !.X, but does not update it ... > > In this case, the preferred fix also involves replacing all occurrences > of !.X with X, but it also involves either deleting the argument > containing !:X (the best option), or, if there is some reason why > the predicate's signature must stay unchanged, to replace !:X with X as well. > And if the clause body does not actually refer to either !.X or !:X, then > *both* arguments represented by !X should be deleted. > The first option is a style warning; the second option, due to the > signature change it may call for, is a non-style warning. We have a growing set of style warnings, and while we do have the option --inhibit-style-warnings to turn them all off, we do not have its converse. I think that it is probably worth adding --enable-all-style-warnings. It may result in a lot of warnings, but it seems preferable to invoking the style options one-by-one (and presumably having to and look up what some of them are in between such invocations). > Both options have a version whose name adds a "-lambda" suffix, and which > does the same warnings for the heads of lambda expressions, not clauses. > > Note that several of the modules below, include some that help to implement > the warnings also contain code changes that result from *acting* on > the new warnings, e.g. by deleting unneeded statevar arguments. ... > diff --git a/compiler/headvar_names.m b/compiler/headvar_names.m > index 5a2cdfd04..3b71eb64d 100644 > --- a/compiler/headvar_names.m > +++ b/compiler/headvar_names.m > @@ -22,13 +22,28 @@ > :- import_module libs. > :- import_module libs.globals. > > +:- import_module list. > + > +:- type maybe_look_for_unused_statevars > + ---> do_not_look_for_unused_statevars > + % No clause had any unused state variables. > + ; look_for_unused_statevars(list(string)). > + % At least one clause had unused state variables. > + % The argument gives, for each head variable, > + % either its the consensus name (if it has one), > + % or an empty string (if it does not). > + % (pre_typecheck.m uses that info to decide whether an unused > + % state variable in one clause is justified by consistency > + % with anoher clause that *does* use that same state variable.) s/anoher/another/ That looks fine otherwise. Julien. From zoltan.somogyi at runbox.com Sun May 18 07:25:24 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 18 May 2025 07:25:24 +1000 (AEST) Subject: [m-rev.] for review: warn about unneeded initial and final state vars In-Reply-To: References: Message-ID: On Sun, 18 May 2025 02:32:17 +1000, Julien Fischer wrote: > On Fri, 16 May 2025 at 03:46, Zoltan Somogyi wrote: > > Add options to warn about unused state vars. > > + % with anoher clause that *does* use that same state variable.) > > s/anoher/another/ Fixed. > That looks fine otherwise. Thanks for that. Attached is the rest of changes called for by the new warnings, again for review by anyone. (There was a lot of unnecessary passing of state vars, so it's big.) I have bootchecked an earlier version of this diff with -O5 --intermod-opt in hlc.gc, asm_fast.gc and in a debug grade, but will repeat all three before commit. This evening, I expect to post for review an entry for NEWS.md. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.usw2 Type: application/octet-stream Size: 2949 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sun May 18 07:33:40 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 18 May 2025 07:33:40 +1000 (AEST) Subject: [m-rev.] for review: warn about unneeded initial and final state vars In-Reply-To: References: Message-ID: On Sun, 18 May 2025 02:32:17 +1000, Julien Fischer wrote: > We have a growing set of style warnings, and while we do have the option > --inhibit-style-warnings to turn them all off, we do not have its converse. I > think that it is probably worth adding --enable-all-style-warnings. It may > result in a lot of warnings, but it seems preferable to invoking the style > options one-by-one (and presumably having to and look up what some of them are > in between such invocations). That is a good idea. We should also consider doing a similar group enable/disable mechanism for options like the new --warn-unused-final-statevars, which straddle the line between being style options and "warning about possible incorrectness" options. (Though offhand I can't think of another option in that category, there may be some.) Before implementing it, I intend to reorganize the order of the warning options, because at the moment, we have related options that are not listed next to each other. I will post a proposed order for review before effecting the reordering it requires. Zoltan. From jfischer at opturion.com Sun May 18 20:43:46 2025 From: jfischer at opturion.com (Julien Fischer) Date: Sun, 18 May 2025 20:43:46 +1000 Subject: [m-rev.] for review: warn about unneeded initial and final state vars In-Reply-To: References: Message-ID: On Sun, 18 May 2025 at 07:25, Zoltan Somogyi wrote: > > > > On Sun, 18 May 2025 02:32:17 +1000, Julien Fischer wrote: > > > On Fri, 16 May 2025 at 03:46, Zoltan Somogyi wrote: > > > Add options to warn about unused state vars. > > > + % with anoher clause that *does* use that same state variable.) > > > > s/anoher/another/ > > Fixed. > > > That looks fine otherwise. > > Thanks for that. Attached is the rest of changes called for by the > new warnings, again for review by anyone. (There was a lot of unnecessary > passing of state vars, so it's big.) You haven't attached the diff there. Julien. From zoltan.somogyi at runbox.com Sun May 18 20:46:32 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 18 May 2025 20:46:32 +1000 (AEST) Subject: [m-rev.] for review: warn about unneeded initial and final state vars In-Reply-To: References: Message-ID: On Sun, 18 May 2025 20:43:46 +1000, Julien Fischer wrote: > > Thanks for that. Attached is the rest of changes called for by the > > new warnings, again for review by anyone. (There was a lot of unnecessary > > passing of state vars, so it's big.) > > You haven't attached the diff there. Sorry about that. Attached now. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.usw2 Type: application/octet-stream Size: 2949 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.usw2.gz Type: application/x-gzip Size: 43502 bytes Desc: not available URL: From jfischer at opturion.com Sun May 18 22:29:54 2025 From: jfischer at opturion.com (Julien Fischer) Date: Sun, 18 May 2025 22:29:54 +1000 Subject: [m-rev.] for review: warn about unneeded initial and final state vars In-Reply-To: References: Message-ID: On Sun, 18 May 2025 at 07:25, Zoltan Somogyi wrote: > > On Sun, 18 May 2025 02:32:17 +1000, Julien Fischer wrote: > > > On Fri, 16 May 2025 at 03:46, Zoltan Somogyi wrote: > > > Add options to warn about unused state vars. > > > + % with anoher clause that *does* use that same state variable.) > > > > s/anoher/another/ > > Fixed. > > > That looks fine otherwise. > > Thanks for that. Attached is the rest of changes called for by the > new warnings, again for review by anyone. (There was a lot of unnecessary > passing of state vars, so it's big.) > Act on all remaining warnings about unused state vars. ... That's fine. Julien. From zoltan.somogyi at runbox.com Mon May 19 02:42:52 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 19 May 2025 02:42:52 +1000 (AEST) Subject: [m-rev.] for post-commit review and opinions: warn option classification Message-ID: Before proposing a reorder of the warning options, I think we need to agree on their classification. The attached diff proposes a classification, with each ZZZ comment after an option signifying that it proposes a different classification for the line's option compared to the functions that return the set of style and non-style options. The WARN_PROPOSAL file lists these changes in a more readable form. Once we agree on the new classification, we can replace those functions with calls to solutions with oc_warn_{s,ns}, or their replacements, respectively. For opinions by everyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: WARN_PROPOSAL Type: application/octet-stream Size: 1418 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.warnopts Type: application/octet-stream Size: 377 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.warnopts Type: application/octet-stream Size: 14395 bytes Desc: not available URL: From jfischer at opturion.com Mon May 19 15:41:59 2025 From: jfischer at opturion.com (Julien Fischer) Date: Mon, 19 May 2025 15:41:59 +1000 Subject: [m-rev.] for post-commit review and opinions: warn option classification In-Reply-To: References: Message-ID: Hi, This is a review of the diff; I'll look at the proposal separately. On Mon, 19 May 2025 at 02:43, Zoltan Somogyi wrote: > Split the oc_warn option category into four parts ... > > ... which contain respectively > > - oc_warn_c: options that control other warnings, > - oc_warn_ns: options that warn about possible bugs (non-style warnings) > - oc_warn_s: style warnings > - oc_warn_i: requests for information I suggest: oc_warn_control oc_warn_correctness oc_warn_style oc_inform I don't think brevity helps in this case. The diff is fine. Julien. From zoltan.somogyi at runbox.com Mon May 19 16:24:17 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 19 May 2025 16:24:17 +1000 (AEST) Subject: [m-rev.] for post-commit review and opinions: warn option classification In-Reply-To: References: Message-ID: On Mon, 19 May 2025 15:41:59 +1000, Julien Fischer wrote: > This is a review of the diff; I'll look at the proposal separately. The two have almost the same info; most of the proposal just *explains* the changes in the diff. > > - oc_warn_c: options that control other warnings, > > - oc_warn_ns: options that warn about possible bugs (non-style warnings) > > - oc_warn_s: style warnings > > - oc_warn_i: requests for information > > I suggest: > > oc_warn_control > oc_warn_correctness > oc_warn_style > oc_inform > > I don't think brevity helps in this case. It very much does. Without it, the clauses of the optdef predicate don't usually fit on one line. (And this fact is the reason for the shortness of the "optdef" name.) > The diff is fine. Thank you. Zoltan. From jfischer at opturion.com Mon May 19 16:33:05 2025 From: jfischer at opturion.com (Julien Fischer) Date: Mon, 19 May 2025 16:33:05 +1000 Subject: [m-rev.] for post-commit review and opinions: warn option classification In-Reply-To: References: Message-ID: On Mon, 19 May 2025 at 16:24, Zoltan Somogyi wrote: > > > > On Mon, 19 May 2025 15:41:59 +1000, Julien Fischer wrote: > > This is a review of the diff; I'll look at the proposal separately. > > The two have almost the same info; most of the proposal just *explains* > the changes in the diff. > > > > - oc_warn_c: options that control other warnings, > > > - oc_warn_ns: options that warn about possible bugs (non-style warnings) > > > - oc_warn_s: style warnings > > > - oc_warn_i: requests for information > > > > I suggest: > > > > oc_warn_control > > oc_warn_correctness > > oc_warn_style > > oc_inform > > > > I don't think brevity helps in this case. > > It very much does. Without it, the clauses of the optdef predicate > don't usually fit on one line. (And this fact is the reason for the > shortness of the "optdef" name.) We can abbreviate a little oc_warn_ctrl oc_warn_correct oc_warn_style oc_inform Even though oc_warn_correct is now the longest of the option_categroy constructors, it's now only by one letter. (I'm tempted to rename oc_warn_correct to oc_warn_dodgy ...) Julien. From novalazy at gmail.com Mon May 19 16:39:03 2025 From: novalazy at gmail.com (Peter Wang) Date: Mon, 19 May 2025 16:39:03 +1000 Subject: [m-rev.] for post-commit review and opinions: warn option classification In-Reply-To: References: Message-ID: <20250519163903.GD2517@gmail.com> On Mon, 19 May 2025 16:33:05 +1000 Julien Fischer wrote: > > We can abbreviate a little > > oc_warn_ctrl > oc_warn_correct > oc_warn_style > oc_inform > > Even though oc_warn_correct is now the longest of the option_categroy > constructors, > it's now only by one letter. (I'm tempted to rename oc_warn_correct > to oc_warn_dodgy ...) oc_warn_suspect? Peter From novalazy at gmail.com Mon May 19 16:39:56 2025 From: novalazy at gmail.com (Peter Wang) Date: Mon, 19 May 2025 16:39:56 +1000 Subject: [m-rev.] for post-commit review and opinions: warn option classification In-Reply-To: <20250519163903.GD2517@gmail.com> References: <20250519163903.GD2517@gmail.com> Message-ID: <20250519163956.GF2517@gmail.com> On Mon, 19 May 2025 16:39:03 +1000 Peter Wang wrote: > On Mon, 19 May 2025 16:33:05 +1000 Julien Fischer wrote: > > > > We can abbreviate a little > > > > oc_warn_ctrl > > oc_warn_correct > > oc_warn_style > > oc_inform > > > > Even though oc_warn_correct is now the longest of the option_categroy > > constructors, > > it's now only by one letter. (I'm tempted to rename oc_warn_correct > > to oc_warn_dodgy ...) > > oc_warn_suspect? Or indeed, "sus". Peter From zoltan.somogyi at runbox.com Mon May 19 16:42:26 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 19 May 2025 16:42:26 +1000 (AEST) Subject: [m-rev.] for review: tweak and announce the new options Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.usw3 Type: application/octet-stream Size: 1316 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.usw3 Type: application/octet-stream Size: 25912 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 19 16:54:55 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 19 May 2025 16:54:55 +1000 (AEST) Subject: [m-rev.] for post-commit review and opinions: warn option classification In-Reply-To: <20250519163956.GF2517@gmail.com> References: <20250519163903.GD2517@gmail.com> <20250519163956.GF2517@gmail.com> Message-ID: On Mon, 19 May 2025 16:39:56 +1000, Peter Wang wrote: > On Mon, 19 May 2025 16:39:03 +1000 Peter Wang wrote: > > On Mon, 19 May 2025 16:33:05 +1000 Julien Fischer wrote: > > > > > > We can abbreviate a little > > > > > > oc_warn_ctrl > > > oc_warn_correct > > > oc_warn_style > > > oc_inform > > > > > > Even though oc_warn_correct is now the longest of the option_categroy > > > constructors, > > > it's now only by one letter. (I'm tempted to rename oc_warn_correct > > > to oc_warn_dodgy ...) > > > > oc_warn_suspect? > > Or indeed, "sus". I am fine with any of oc_sus, oc_dodgy and oc_corr (short for correctness). Whatever you pick, I will change to, *after* the diff I just posted for review is committed (to avoid a conflict). Does anyone object to replacing the existing functions that return the list of style and nonstyle options, which have proven to be incomplete with a call to solutions using the new subcategories? The only user visible effect would be that fixing that incompleteness will turn off more warnings in cases where we turn off either just style warnings, or "all" warnings (which previously left some on.) And does anyone object to turning off warnings when creating .*opt files? Here, I can see arguments for both turning them off, and leaving them on. Turning them off would mean that all warnings go into .err files, where they are easy to see and to interpret as "this warning is for this module", neither of which is true for the current system which puts warnings into the stream of output from an invocation of mmake. On the other hand, the current systems makes them "available" to the programmer earlier. For me, since I don't tend to watch mmake output as it is made, turning them off makes more sense. How about you? Zoltan. From jfischer at opturion.com Mon May 19 19:06:49 2025 From: jfischer at opturion.com (Julien Fischer) Date: Mon, 19 May 2025 19:06:49 +1000 Subject: [m-rev.] for review: tweak and announce the new options In-Reply-To: References: Message-ID: On Mon, 19 May 2025 at 16:42, Zoltan Somogyi wrote: > Tweak and announce the unneeded statevar options. ... > diff --git a/NEWS.md b/NEWS.md > index ba8bc5936..49b487f86 100644 > --- a/NEWS.md > +++ b/NEWS.md > @@ -1524,6 +1524,26 @@ Changes to the Mercury compiler > from having to decide on a case-by-case basis exactly where they want > to add a new `import_module` or `use_module` declaration. > > +* We have added two new options, --warn-unneeded-initial-statevars, Mark up command line options in the NEWS file as inline code, so `--warn-unused-unneeded-initial-statevars` here and similarly below. > + and --warn-unneeded-initial-statevars-lambda, which report, for > + clause heads and lambda expressions respectively, when an argument > + of the form !.SV in their argument list is never updated. In most cases, > + changing such arguments into non-statevars will improve the code > + by avoiding giving readers of the code a false expectation of an update. > + (An exception is when a !.SV argument is not updated in one clause, > + but is updated in another clause.) Both options are on by default. > + > +* We have added two new options, --warn-unneeded-final-statevars, > + and --warn-unneeded-final-statevars-lambda, which report, for > + clause heads and lambda expressions respectively, when an argument > + of the form !:SV in their argument list is guaranteed to be unified > + with the !.SV argument in the same argument list. In the absence of > + constraints that require keeping the predicate signature unchanged > + (e.g. to allow the predicate to be passed to a higher order construct), > + the !:SV argument should be deleted, and if the only use of the !.SV > + argument was to set the value of the !:SV argument, then the !.SV > + argument should be deleted too. Both options are on by default. That's fine otherwise. Julien. From zoltan.somogyi at runbox.com Tue May 20 08:30:37 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 20 May 2025 08:30:37 +1000 (AEST) Subject: [m-rev.] diff: document some things about conservative gc Message-ID: This should not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.gc Type: application/octet-stream Size: 237 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.gc Type: application/octet-stream Size: 2022 bytes Desc: not available URL: From jfischer at opturion.com Tue May 20 10:21:47 2025 From: jfischer at opturion.com (Julien Fischer) Date: Tue, 20 May 2025 10:21:47 +1000 Subject: [m-rev.] for post-commit review and opinions: warn option classification In-Reply-To: References: <20250519163903.GD2517@gmail.com> <20250519163956.GF2517@gmail.com> Message-ID: On Mon, 19 May 2025 at 16:54, Zoltan Somogyi wrote: > > On Mon, 19 May 2025 16:39:56 +1000, Peter Wang wrote: > > On Mon, 19 May 2025 16:39:03 +1000 Peter Wang wrote: > > > On Mon, 19 May 2025 16:33:05 +1000 Julien Fischer wrote: > > > > > > > > We can abbreviate a little > > > > > > > > oc_warn_ctrl > > > > oc_warn_correct > > > > oc_warn_style > > > > oc_inform > > > > > > > > Even though oc_warn_correct is now the longest of the option_categroy > > > > constructors, > > > > it's now only by one letter. (I'm tempted to rename oc_warn_correct > > > > to oc_warn_dodgy ...) > > > > > > oc_warn_suspect? > > > > Or indeed, "sus". > > I am fine with any of oc_sus, oc_dodgy and oc_corr (short for correctness). > Whatever you pick, I will change to, *after* the diff I just posted for review > is committed (to avoid a conflict). > > Does anyone object to replacing the existing functions that return the list > of style and nonstyle options, which have proven to be incomplete > with a call to solutions using the new subcategories? The only user visible > effect would be that fixing that incompleteness will turn off more warnings > in cases where we turn off either just style warnings, or "all" warnings > (which previously left some on.) I have no objection. > And does anyone object to turning off warnings when creating .*opt files? Again, no objection from me. Julien. From novalazy at gmail.com Tue May 20 13:01:11 2025 From: novalazy at gmail.com (Peter Wang) Date: Tue, 20 May 2025 13:01:11 +1000 Subject: [m-rev.] for review: warn about unneeded initial and final state vars In-Reply-To: References: Message-ID: <20250520130111.GT3500@gmail.com> On Fri, 16 May 2025 03:46:37 +1000 "Zoltan Somogyi" wrote: > For review by anyone. I will update the user guide once > the new documentation in options.m is approved. > > Much of the diff consists of me acting on the new warnings, > so you can see how useful they are. I have not yet acted on > *all* such warnings, because this diff is large enough already; > that will come later. > > Zoltan > Add options to warn about unused state vars. > > The new --warn-unneeded-initial-statevar option asks the compiler to warn about > code such as > > pred_a(!.X, ...) :- > ... code that uses !.X, but does not update it ... > > In this case, the preferred fix is to just replace all occurrences > of !.X with X. > > The new --warn-unneeded-final-statevar option asks the compiler to warn about > code such as > > pred_a(!X, ...) :- > ... code that maybe uses !.X, but does not update it ... > > In this case, the preferred fix also involves replacing all occurrences > of !.X with X, but it also involves either deleting the argument > containing !:X (the best option), or, if there is some reason why > the predicate's signature must stay unchanged, to replace !:X with X as well. > And if the clause body does not actually refer to either !.X or !:X, then > *both* arguments represented by !X should be deleted. > I've had a chance to try this change on the Prince codebase now. A common pattern is a predicate that takes the I/O state as unique input in order to read the "global state", but the I/O state needs to be threaded through its caller (for whatever reason). For example: :- pred p(int::in, io::di, io::uo) is det. p(_, !IO) :- read_global_state(!.IO). :- pred read_global_state(io::ui) is det. read_global_state(IO) :- ... The unneeded final statevars warning suggests that !:IO could be deleted in p/3, but it cannot be written like so: p(_, IO, IO) :- read_global_state(IO). as the modechecker will complain that IO has instantiatedness `ground'. To avoid the warning, it is necessary to write out the unification previously implied by state variable notation: p(_, IO0, IO) :- read_global_state(IO0), IO = IO0. I guess, ideally, the compiler would recognise that a final statevar is not "unneeded" if the statevar occurs as a unique-input argument in a call (or some generalisation of that). Peter -------------- next part -------------- :- module unique_input. :- interface. :- import_module io. :- pred main(io::di, io::uo) is det. %-----------------------------------------------------------------------------% :- implementation. :- import_module list. main(!IO) :- foldl(p, [], !IO), foldl(q, [], !IO). :- pred p(int::in, io::di, io::uo) is det. p(_, !IO) :- read_global_state(!.IO), read_global_state(!.IO). :- pred q(int::in, io::di, io::uo) is det. q(_, IO0, IO) :- read_global_state(IO0), read_global_state(IO0), IO = IO0. :- pred read_global_state(io::ui) is det. read_global_state(_). From zoltan.somogyi at runbox.com Tue May 20 17:13:42 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 20 May 2025 17:13:42 +1000 (AEST) Subject: [m-rev.] for review: warn about unneeded initial and final state vars In-Reply-To: <20250520130111.GT3500@gmail.com> References: <20250520130111.GT3500@gmail.com> Message-ID: On Tue, 20 May 2025 13:01:11 +1000, Peter Wang wrote: > I've had a chance to try this change on the Prince codebase now. > A common pattern is a predicate that takes the I/O state as unique input > in order to read the "global state", but the I/O state needs to be > threaded through its caller (for whatever reason). > > For example: > > :- pred p(int::in, io::di, io::uo) is det. > > p(_, !IO) :- > read_global_state(!.IO). > > :- pred read_global_state(io::ui) is det. > > read_global_state(IO) :- ... > > The unneeded final statevars warning suggests that !:IO could be deleted > in p/3, but it cannot be written like so: > > p(_, IO, IO) :- > read_global_state(IO). > > as the modechecker will complain that IO has instantiatedness `ground'. > > To avoid the warning, it is necessary to write out the unification > previously implied by state variable notation: > > p(_, IO0, IO) :- > read_global_state(IO0), > IO = IO0. > > I guess, ideally, the compiler would recognise that a final statevar is > not "unneeded" if the statevar occurs as a unique-input argument in a > call (or some generalisation of that). The code that generates warnings just about has to gather information about state var usage during the parse tree to HLDS conversion process, because state variables effectively become invisible in the result of the translation, except for their effects on variable names. And the code that looks at clause heads just about has to operate before mode analysis, because the copy-clauses-to-procs pass that precedes mode analysis effectively obsoletes clause information. This means that this code cannot base its decisions on the answers to questions such as "what is the mode of this argument"; it has to fall back to questions "what are the *possible* modes of this argument". In this case, I think that still works. We could add a heuristic that says "do not generate an unneeded final statevar warning if either the initial or the final inst of the argument represented by that final statevar, in *any* of the declared modes of the predicate, involve either uniqueness, or its converse, being clobbered". Would that work to shut up the unwanted warnings for the cases you have seen? And can you think of any other heuristic that would help in other cases of false positives? Note that this approach has the minor disadvantage that it works only on declared modes, not inferred ones, since these are not available when the warnings are generated. But since mode inference does a lousy job on any code involving uniqueness, I don't think that is a serious limitation. Zoltan. From jfischer at opturion.com Wed May 21 01:40:37 2025 From: jfischer at opturion.com (Julien Fischer) Date: Wed, 21 May 2025 01:40:37 +1000 Subject: [m-rev.] for review: warn about unneeded initial and final state vars In-Reply-To: References: Message-ID: On Sun, 18 May 2025 at 22:29, Julien Fischer wrote: > > On Sun, 18 May 2025 at 07:25, Zoltan Somogyi wrote: > > > > On Sun, 18 May 2025 02:32:17 +1000, Julien Fischer wrote: > > > > > On Fri, 16 May 2025 at 03:46, Zoltan Somogyi wrote: > > > > Add options to warn about unused state vars. > > > > + % with anoher clause that *does* use that same state variable.) > > > > > > s/anoher/another/ > > > > Fixed. > > > > > That looks fine otherwise. > > > > Thanks for that. Attached is the rest of changes called for by the > > new warnings, again for review by anyone. (There was a lot of unnecessary > > passing of state vars, so it's big.) > > > Act on all remaining warnings about unused state vars. > > ... > > That's fine. Actually, it wasn't quite fine :-( A number of clauses that are only used in non-C grades trigger the new warning, some due to the issue that Peter reported elsewhere in this thread. I have committed a fix for these issues. Julien. From novalazy at gmail.com Wed May 21 13:05:40 2025 From: novalazy at gmail.com (Peter Wang) Date: Wed, 21 May 2025 13:05:40 +1000 Subject: [m-rev.] for review: warn about unneeded initial and final state vars In-Reply-To: References: <20250520130111.GT3500@gmail.com> Message-ID: <20250521130540.GB2483@gmail.com> On Tue, 20 May 2025 17:13:42 +1000 "Zoltan Somogyi" wrote: > This means that this code cannot base its decisions on the answers > to questions such as "what is the mode of this argument"; it has to > fall back to questions "what are the *possible* modes of this argument". > In this case, I think that still works. We could add a heuristic that says > "do not generate an unneeded final statevar warning if either the initial > or the final inst of the argument represented by that final statevar, > in *any* of the declared modes of the predicate, involve either > uniqueness, or its converse, being clobbered". > > Would that work to shut up the unwanted warnings for the cases > you have seen? And can you think of any other heuristic that would help > in other cases of false positives? That would work. I can't think of anything else right now. Peter From zoltan.somogyi at runbox.com Thu May 22 02:24:23 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 22 May 2025 02:24:23 +1000 (AEST) Subject: [m-rev.] for post-commit review: improve comments in string.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.str Type: application/octet-stream Size: 4611 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Thu May 22 09:04:03 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 22 May 2025 09:04:03 +1000 (AEST) Subject: [m-rev.] diff: break up some large predicates in add_pred.m Message-ID: This does not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.ap Type: application/octet-stream Size: 165 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.ap Type: application/octet-stream Size: 25725 bytes Desc: not available URL: From jfischer at opturion.com Thu May 22 10:18:24 2025 From: jfischer at opturion.com (Julien Fischer) Date: Thu, 22 May 2025 10:18:24 +1000 Subject: [m-rev.] for post-commit review: improve comments in string.m In-Reply-To: References: Message-ID: On Thu, 22 May 2025 at 02:24, Zoltan Somogyi wrote: > > diff --git a/library/string.m b/library/string.m > index f55b08475..475063841 100644 > --- a/library/string.m > +++ b/library/string.m ... > @@ -50,6 +50,7 @@ > % This module is divided into several sections. These sections are: > % > % - Wrapper types that associate particular semantics with raw strings. > +% - Identifying the UTF version used by the current platform. s/UTF/Unicode encoding form/ The rest looks fine. Julien. From zoltan.somogyi at runbox.com Thu May 22 10:47:32 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 22 May 2025 10:47:32 +1000 (AEST) Subject: [m-rev.] diff: improve goal_util.m's style Message-ID: This does not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.gu Type: application/octet-stream Size: 367 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.gu Type: application/octet-stream Size: 46008 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Thu May 22 12:21:48 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 22 May 2025 12:21:48 +1000 (AEST) Subject: [m-rev.] for review: warn about unneeded initial and final state vars In-Reply-To: <20250521130540.GB2483@gmail.com> References: <20250520130111.GT3500@gmail.com> <20250521130540.GB2483@gmail.com> Message-ID: On Wed, 21 May 2025 13:05:40 +1000, Peter Wang wrote: > On Tue, 20 May 2025 17:13:42 +1000 "Zoltan Somogyi" wrote: > > This means that this code cannot base its decisions on the answers > > to questions such as "what is the mode of this argument"; it has to > > fall back to questions "what are the *possible* modes of this argument". > > In this case, I think that still works. We could add a heuristic that says > > "do not generate an unneeded final statevar warning if either the initial > > or the final inst of the argument represented by that final statevar, > > in *any* of the declared modes of the predicate, involve either > > uniqueness, or its converse, being clobbered". > > > > Would that work to shut up the unwanted warnings for the cases > > you have seen? And can you think of any other heuristic that would help > > in other cases of false positives? > > That would work. I can't think of anything else right now. The attached diff implements the agreed approach, and also uses different forms of the diagnostic depending on whether only the final version is unneeded, or both the initial and final versions. Note that this diff implements both this distinction, and the new heuristic, only for state vars in clause heads, not in lambda expressions. I will update the code for lambda expressions after this diff is reviewed and committed. For review by Peter. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.usw4 Type: application/octet-stream Size: 1739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.usw4 Type: application/octet-stream Size: 31228 bytes Desc: not available URL: From novalazy at gmail.com Thu May 22 14:19:25 2025 From: novalazy at gmail.com (Peter Wang) Date: Thu, 22 May 2025 14:19:25 +1000 Subject: [m-rev.] for review: warn about unneeded initial and final state vars In-Reply-To: References: <20250520130111.GT3500@gmail.com> <20250521130540.GB2483@gmail.com> Message-ID: <20250522141925.GE2519@gmail.com> On Thu, 22 May 2025 12:21:48 +1000 "Zoltan Somogyi" wrote: > Refine unused final statevar warnings. > > diff --git a/compiler/pre_typecheck.m b/compiler/pre_typecheck.m > index f36558037..ce43cb464 100644 > --- a/compiler/pre_typecheck.m > +++ b/compiler/pre_typecheck.m > @@ -423,64 +436,224 @@ warn_about_any_unneeded_initial_statevars(PredInfo, HeadVars, > > %---------------------% > > +:- pred maybe_warn_about_unneeded_final_statevar(module_info::in, > + pred_info::in, set(string)::in, prog_context::in, list(clause)::in, > + uint::in, init_and_final::in, > + list(error_spec)::in, list(error_spec)::out) is det. > + > +maybe_warn_about_unneeded_final_statevar(ModuleInfo, PredInfo, > + BodyVarSVarNameSet, HeadClauseContext, TailClauses, > + InitArgNum, InitAndFinal, !Specs) :- > + InitAndFinal = init_and_final(FinalArgNum, SVarNameSet), > + set.intersect(BodyVarSVarNameSet, SVarNameSet, SVarNameSetInBody), > + ( if set.is_non_empty(SVarNameSetInBody) then > + % The body of at least one clause in the definition of this predicate > + % (as opposed to the clause heads) contains a reference to an initial > + % or to a final version of this state var. We should therefore report > + % that only the *final* statevar argument is unneeded. > + % > + % There is one exception to this. For state variables that represent > + % unique state, accessing the initial version *and preserving > + % uniqueness in a way that is visible to the caller* requires > + % returning a new version of the state var, so that its mode > + % can tell the caller that the returned reference is still unique. > + ( if > + pred_args_are_free_of_declared_uniqueness(ModuleInfo, PredInfo, > + InitArgNum, FinalArgNum) > + then > + warn_about_unneeded_final_statevar(PredInfo, HeadClauseContext, > + TailClauses, FinalArgNum, SVarNameSet, !Specs) > + else > + true > + ) > + else > + % The definition of this predicate is missing not only any middle > + % occurrence of this state var, it is also missing any initial > + % or final occurrence, except in the clause heads. > + % We should therefore report that *both* arguments are unneeded. > + % > + % Uniqueness concerns do not apply here, because if the programmer > + % deletes both arguments, the reference to the unique state that > + % the caller would have passed to PredInfo is still available to it. PredInfo -> to the predicate > + warn_about_unneeded_initial_final_statevar(PredInfo, HeadClauseContext, > + TailClauses, InitArgNum, FinalArgNum, SVarNameSet, !Specs) > + ). > + > +%---------------------% > + > +:- pred gather_clause_body_vars(clause::in, > + set_of_progvar::in, set_of_progvar::out) is det. I suggest renaming this to gather_clause_body_non_svar_copy_vars or similar. > + > +gather_clause_body_vars(Clause, !BodyVars) :- > + BodyGoal = Clause ^ clause_body, > + % Note that even for clauses that are facts in the source code, > + % such as "noop(!IO).", will contain a nonempty body goal, since > + % the conversion to HLDS will create a clause of the form > + % > + % noop(STATE_VARIABLE_IO_0, STATE_VARIABLE_IO) :- > + % STATE_VARIABLE_IO = STATE_VARIABLE_IO_0. > + % > + % What our caller wants to know, for a given state var, is not > + % "do progvars representing versions of this state var occur in the > + % body goal of the clause", because we know in advance that for any > + % state var that occurs in the clause head, the answer must be "yes". > + % What it wants to know instead is "do progvars representing versions > + % of this state var occur in the body goal of the clause *outside of" > + % unify goals that just copy state var values". I suggest: "body goal of the clause" -> "clause body" "outside of" -> "other than" > + % > + % Here we gather the data that allows our caller to answer that question > + % for any state var. > + non_svar_copy_goal_vars(BodyGoal, BodyGoalVars), > + set_of_var.union(BodyGoalVars, !BodyVars). > + > diff --git a/compiler/state_var.m b/compiler/state_var.m > index 8527a4de6..b113f56eb 100644 > --- a/compiler/state_var.m > +++ b/compiler/state_var.m > @@ -605,6 +614,57 @@ new_state_var_instance(StateVar, NameSource, Var, !UrInfo) :- > initial_state_var_name(SVarName) = ProgVarName :- > ProgVarName = string.format("STATE_VARIABLE_%s_0", [s(SVarName)]). > > +is_prog_var_for_some_state_var(VarSet, Var, SVarName) :- > + % All prog_vars representing state vars are named. > + varset.search_name(VarSet, Var, VarName), > + string.remove_prefix("STATE_VARIABLE_", VarName, AfterStdPrefix), > + UnderscoreSeparatedPieces = string.split_at_char('_', AfterStdPrefix), > + ( > + UnderscoreSeparatedPieces = [], > + % There is no underscore, so there can be no numerical suffix. > + SVarName = AfterStdPrefix > + ; > + UnderscoreSeparatedPieces = [_ | _], > + list.det_last(UnderscoreSeparatedPieces, LastPiece), > + string.to_int(LastPiece, _N), > + % This is either the initial or a middle version of SVarName. > + % (Initial if _N is zero, and middle otherwise) > + NumericalSuffix = "_" ++ LastPiece, > + SVarName = string.det_remove_suffix(AfterStdPrefix, NumericalSuffix) > + ). You could use string.find_last_char and string.unsafe_between. > diff --git a/tests/warnings/unneeded_final_statevar.m b/tests/warnings/unneeded_final_statevar.m > index e69de29bb..6e24ec7c4 100644 > --- a/tests/warnings/unneeded_final_statevar.m > +++ b/tests/warnings/unneeded_final_statevar.m > @@ -0,0 +1,44 @@ > +%---------------------------------------------------------------------------% > +% vim: ts=4 sw=4 et ft=mercury > +%---------------------------------------------------------------------------% > + > +:- module unneeded_final_statevar. > +:- interface. > +:- import_module io. > + > +:- pred p1(io::di, io::uo) is det. > +:- pred p2(int::mdi, int::muo) is semidet. > +:- pred p3(int::mdi, int::muo) is semidet. > + > +%---------------------------------------------------------------------------% > + > +:- implementation. > +:- import_module int. > + > +%---------------------------------------------------------------------------% > + > +% p1 should not get a warning, due to the heuristic rule that says > +% "do not generate unused final statevar warnings for a predicate > +% if it is defineing clauses are all facts". defining I have tested the patch, and it appears to work well. Thanks. Peter From zoltan.somogyi at runbox.com Thu May 22 20:01:30 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 22 May 2025 20:01:30 +1000 (AEST) Subject: [m-rev.] for review: warn about unneeded initial and final state vars In-Reply-To: <20250522141925.GE2519@gmail.com> References: <20250520130111.GT3500@gmail.com> <20250521130540.GB2483@gmail.com> <20250522141925.GE2519@gmail.com> Message-ID: On Thu, 22 May 2025 14:19:25 +1000, Peter Wang wrote: > On Thu, 22 May 2025 12:21:48 +1000 "Zoltan Somogyi" wrote: > > Refine unused final statevar warnings. > > + UnderscoreSeparatedPieces = [_ | _], > > + list.det_last(UnderscoreSeparatedPieces, LastPiece), > > + string.to_int(LastPiece, _N), > > + % This is either the initial or a middle version of SVarName. > > + % (Initial if _N is zero, and middle otherwise) > > + NumericalSuffix = "_" ++ LastPiece, > > + SVarName = string.det_remove_suffix(AfterStdPrefix, NumericalSuffix) > > + ). > > You could use string.find_last_char and string.unsafe_between. The code is executed so rarely there is no point in optimizing it, so I would prefer to avoid unsafe code. I followed all your other suggestions. Thanks for the review. > I have tested the patch, and it appears to work well. Thanks. You are welcome. Zoltan. From zoltan.somogyi at runbox.com Thu May 22 22:54:32 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 22 May 2025 22:54:32 +1000 (AEST) Subject: [m-rev.] for post-commit review: carve five new modules out of goal_util.m Message-ID: For review by anyone. The diff is big, but the only part worth reviewing is the change to notes/compiler_design.html, including the names of the new modules. The rest is just code being moved around, or updates to include_modules. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.gu Type: application/octet-stream Size: 1080 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.gu.gz Type: application/x-gzip Size: 31965 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Fri May 23 01:22:27 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 23 May 2025 01:22:27 +1000 (AEST) Subject: [m-rev.] diff: give a few predicates more descriptive names Message-ID: This does not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.gv Type: application/octet-stream Size: 208 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.gv Type: application/octet-stream Size: 24337 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Fri May 23 12:15:19 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 23 May 2025 12:15:19 +1000 (AEST) Subject: [m-rev.] for review: turn off all warnings when making .int*/.*opt files Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.opt1 Type: application/octet-stream Size: 1279 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.opt1 Type: application/octet-stream Size: 30437 bytes Desc: not available URL: From jfischer at opturion.com Fri May 23 15:50:11 2025 From: jfischer at opturion.com (Julien Fischer) Date: Fri, 23 May 2025 15:50:11 +1000 Subject: [m-rev.] for review: turn off all warnings when making .int*/.*opt files In-Reply-To: References: Message-ID: On Fri, 23 May 2025 at 12:15, Zoltan Somogyi wrote: > > Turn off all warnings when making .int*/.*opt files. > > compiler/options.m: > Switch to using the same signature for all the operations that > return sets of warning and related options. (They return them > as lists, because that is what their callers need.) > > Implement all these operations in terms of a option categories. > This avoids the need to maintain separate two separate lists > of warning options, and to create a third list of inform options. > > Add a new mode to the optdef predicate to speed up such operations. > > Give the various categories of warning/inform options longer, > more meaningful names. > > Give the operation exported for make.track_flags.m > a more descriptive name. > > compiler/handle_options.m: > Turn off all non-style warning options when making .int* files, > not just some. Also turn off all inform options. (We already > turned off all style warnings.) > > Turn off all warning and inform options also when making .*opt files. > > Factor out the commonalities in the handling of these op_modes. > > compiler/mercury_compile_augment.m: > Don't turn off warning options when making .*opt files, > since handle_options.m has already handled that task. > > compiler/make.track_flags.m: > Conform to the changes above. That's fine. Julien. From jfischer at opturion.com Fri May 23 17:45:42 2025 From: jfischer at opturion.com (Julien Fischer) Date: Fri, 23 May 2025 17:45:42 +1000 Subject: [m-rev.] for post-commit review: carve five new modules out of goal_util.m In-Reply-To: References: Message-ID: On Thu, 22 May 2025 at 22:54, Zoltan Somogyi wrote: > > Carve five new modules out of goal_util.m. ... > compiler/notes/compiler_design.html: > Include and document the new modules. That's fine. Julien. From zoltan.somogyi at runbox.com Fri May 23 23:21:55 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 23 May 2025 23:21:55 +1000 (AEST) Subject: [m-rev.] for review: structured representation of option documentation Message-ID: I am proposing that we switch from our current stringly-typed representation of option help text to a strongly-typed representation :-) The attached diff shows the general form of I am proposing for that representation. If people agree that this is a good idea, then I will convert the documentation of all the other options as well. For reviews/opinions by anyone and everyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.opt2 Type: application/octet-stream Size: 172 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.opt2 Type: application/octet-stream Size: 5887 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sun May 25 08:46:33 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 25 May 2025 08:46:33 +1000 (AEST) Subject: [m-rev.] =?utf-8?q?for_review=3A_structured_representation_of_opt?= =?utf-8?q?ion=09documentation?= In-Reply-To: References: Message-ID: On Fri, 23 May 2025 23:21:55 +1000 (AEST), "Zoltan Somogyi" wrote: > I am proposing that we switch from our current stringly-typed > representation of option help text to a strongly-typed representation :-) > The attached diff shows the general form of I am proposing for that > representation. If people agree that this is a good idea, then I will > convert the documentation of all the other options as well. > > For reviews/opinions by anyone and everyone. In the absence of a review, or a promise of one, I will assume that noone objects, and will commit this tonight, and then go on to the rest of the options. Zoltan. From jfischer at opturion.com Sun May 25 14:50:29 2025 From: jfischer at opturion.com (Julien Fischer) Date: Sun, 25 May 2025 14:50:29 +1000 Subject: [m-rev.] for review: structured representation of option documentation In-Reply-To: References: Message-ID: On Fri, 23 May 2025 at 23:22, Zoltan Somogyi wrote: > > I am proposing that we switch from our current stringly-typed > representation of option help text to a strongly-typed representation :-) > The attached diff shows the general form of I am proposing for that > representation. If people agree that this is a good idea, then I will > convert the documentation of all the other options as well. > Prototype a better way to store option documentation. > > compiler/options.m: > Implement a more structured representation of option documentation, > and use it one case. ... use it *in* one case. I don't have any objections to this change, since it is an improvement on the status quo. Ideally, we would have a mechanism for doing this as part of getopt.m, but coming up with a sufficiently generic design for that kind of thing is tough. > diff --git a/compiler/options.m b/compiler/options.m > index 234b29dab..b1a64c67b 100644 > --- a/compiler/options.m > +++ b/compiler/options.m > @@ -4450,8 +4450,9 @@ handle_quoted_flag(Option, Flag, !OptionTable) :- > %---------------------------------------------------------------------------% > > options_help(Stream, !IO) :- > - io.write_string(Stream, "\t-?, -h, --help\n", !IO), > - io.write_string(Stream, "\t\tPrint this usage message.\n", !IO), > + OptHelpHelp = gen_help("help", [], ['?', 'h'], no_arg, help_public, > + ["Print this usage message."]), > + output_help_messages(Stream, [OptHelpHelp], !IO), > options_help_warning(Stream, !IO), > options_help_verbosity(Stream, !IO), > options_help_output(Stream, !IO), > @@ -7252,6 +7253,129 @@ options_help_misc(Stream, !IO) :- > "\tonly be processed for implicit parallelism." > ], !IO). > > +%---------------------------------------------------------------------------% > +% > +% XXX The code from here to the end of the file should be in another file, > +% since options.m is big enough already :-(. > +% > +% This structured representation improves on our traditional approach > +% of storing just lists of lines in the following ways. > +% > +% - It does not force us to start every line documenting an option > +% with "\tactual help text". > +% > +% - It does not require global changes to change indentation levels. > +% > +% - It allows an optional check, probably inside a trace scope, that tests > +% each first and each later line whether they fit on a standard > +% 80 column line, and adds an easily greppable marker if any > +% exceeds that limit. Does that matter if we are reflowing the lines wrt to a line width parameter anyway, as per the next point? > +% - It allows taking a line width parameter, and reflowing the later lines > +% to respect that limit. > +% > +% - It allows adding a version of output_help_messages that outputs > +% the help message not to be read by a compiler user, but with > +% texinfo markup, intended to be copy-and-pasted into doc/user_guide.texi. > +% > + > +:- type help > + ---> gen_help( > + % The name of the option. > + gh_long_name :: string, > + > + % Any alternate names of the option. > + % We have many options that have both British and American > + % spelling of the option name, and some have both > + % short and long versions. > + gh_alt_long_names :: list(string), Is the order of this list significant? Is the order intended to be reflected in the order of the output. If so, I suggest adding a comment saying so. It may be useful to capture whether the option is negated by default here or not. That way the addition of the "--no-" prefix can be handled automatically. > + > + % Every character in this field is a short name of the option. > + gh_short_names :: list(char), Ditto about order here. > + > + % If the option takes an argument, then this should contain > + % the name of the placeholder for that argument. > + gh_maybe_arg :: maybe_opt_arg, > + > + % Is the option's documentation printed for users, or not? > + gh_public_or_private :: help_public_or_private, Presumably, we could support something like --developer-help, which will include the undocumented options in the usage message. (That would be useful as I often find myself having to go and consult options.m for details about them.) > + > + % The lines describing the effect of the option. > + gh_description :: list(string) In the longer term, we should consider moving to a more structure markup of the description (something like what error_util does for error/warning messages). That's fine otherwise. Julien. From jfischer at opturion.com Sun May 25 14:58:22 2025 From: jfischer at opturion.com (Julien Fischer) Date: Sun, 25 May 2025 14:58:22 +1000 Subject: [m-rev.] for review: structured representation of option documentation In-Reply-To: References: Message-ID: Another thought on this ... On Fri, 23 May 2025 at 23:22, Zoltan Somogyi wrote: > diff --git a/compiler/options.m b/compiler/options.m > index 234b29dab..b1a64c67b 100644 > --- a/compiler/options.m > +++ b/compiler/options.m ... > +:- type help > + ---> gen_help( This type should contain a field that gives a link (e.g. a field gh_option) to the relevant member of the option/0 type. That way the usage message processor could look up details of the option, like its default value, using the usual predicates. (Doing this will also make it more likely that the documentation is updated if the option is changed or deleted.) > + % The name of the option. > + gh_long_name :: string, > + > + % Any alternate names of the option. > + % We have many options that have both British and American > + % spelling of the option name, and some have both > + % short and long versions. > + gh_alt_long_names :: list(string), > + > + % Every character in this field is a short name of the option. > + gh_short_names :: list(char), > + > + % If the option takes an argument, then this should contain > + % the name of the placeholder for that argument. > + gh_maybe_arg :: maybe_opt_arg, > + > + % Is the option's documentation printed for users, or not? > + gh_public_or_private :: help_public_or_private, > + > + % The lines describing the effect of the option. > + gh_description :: list(string) > + ) Julien. From zoltan.somogyi at runbox.com Sun May 25 16:25:51 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 25 May 2025 16:25:51 +1000 (AEST) Subject: [m-rev.] for review: structured representation of option documentation In-Reply-To: References: Message-ID: On Sun, 25 May 2025 14:50:29 +1000, Julien Fischer wrote: > > +%---------------------------------------------------------------------------% > > +% > > +% XXX The code from here to the end of the file should be in another file, > > +% since options.m is big enough already :-(. > > +% > > +% This structured representation improves on our traditional approach > > +% of storing just lists of lines in the following ways. > > +% > > +% - It does not force us to start every line documenting an option > > +% with "\tactual help text". > > +% > > +% - It does not require global changes to change indentation levels. > > +% > > +% - It allows an optional check, probably inside a trace scope, that tests > > +% each first and each later line whether they fit on a standard > > +% 80 column line, and adds an easily greppable marker if any > > +% exceeds that limit. > > Does that matter if we are reflowing the lines wrt to a line width parameter > anyway, as per the next point? No, it doesn't. Those two are alternatives, and I don't know whether reflow is required. > > +% - It allows taking a line width parameter, and reflowing the later lines > > +% to respect that limit. > > +% > > +% - It allows adding a version of output_help_messages that outputs > > +% the help message not to be read by a compiler user, but with > > +% texinfo markup, intended to be copy-and-pasted into doc/user_guide.texi. > > +% > > + > > +:- type help > > + ---> gen_help( > > + % The name of the option. > > + gh_long_name :: string, > > + > > + % Any alternate names of the option. > > + % We have many options that have both British and American > > + % spelling of the option name, and some have both > > + % short and long versions. > > + gh_alt_long_names :: list(string), > > Is the order of this list significant? Is the order intended to be reflected > in the order of the output. If so, I suggest adding a comment saying so. It is the order of output. I added that comment. > It may be useful to capture whether the option is negated by default here or > not. That way the addition of the "--no-" prefix can be handled automatically. > > > + > > + % Every character in this field is a short name of the option. > > + gh_short_names :: list(char), > > Ditto about order here. Done, though "help" is the only option with more than one short name. (The set of chars available as short names is limited, after all.) > > + > > + % If the option takes an argument, then this should contain > > + % the name of the placeholder for that argument. > > + gh_maybe_arg :: maybe_opt_arg, > > + > > + % Is the option's documentation printed for users, or not? > > + gh_public_or_private :: help_public_or_private, > > Presumably, we could support something like --developer-help, which will > include the undocumented options in the usage message. (That would be useful as > I often find myself having to go and consult options.m for details about them.) Yes, we could. I will modify the print code to take a flag controlling whether we print private options. > > + > > + % The lines describing the effect of the option. > > + gh_description :: list(string) > > In the longer term, we should consider moving to a more structure markup of the > description (something like what error_util does for error/warning messages). Agreed, but I am pretty sure that it would be overkill for the vast majority of options. And for the ones for which it would not be overkill, it will take conversion to *this* form to discover what extra structure *would* be useful. > That's fine otherwise. Thanks. I followed your other suggestions. Zoltan. From zoltan.somogyi at runbox.com Sun May 25 17:10:43 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 25 May 2025 17:10:43 +1000 (AEST) Subject: [m-rev.] for review: structured representation of option documentation In-Reply-To: References: Message-ID: On Sun, 25 May 2025 14:58:22 +1000, Julien Fischer wrote: > Another thought on this ... > > On Fri, 23 May 2025 at 23:22, Zoltan Somogyi wrote: > > > diff --git a/compiler/options.m b/compiler/options.m > > index 234b29dab..b1a64c67b 100644 > > --- a/compiler/options.m > > +++ b/compiler/options.m > > ... > > > +:- type help > > + ---> gen_help( > > > This type should contain a field that gives a link (e.g. a field gh_option) to > the relevant member of the option/0 type. That way the usage message processor > could look up details of the option, like its default value, using the usual > predicates. I don't think that lookup would be worthwhile. It would help with the trivial part of writing the message (converting --long-name to --no-long-name), but not with the harder part, which is writing the main description in the negative instead of the positive form. In many cases, the difference will be just "disable" vs "enable", but in other cases, the change would be different, and I don't think it can be usefully automated. > (Doing this will also make it more likely that the documentation > is updated if the option is changed or deleted.) Agreed. That link from the help structure to the option/0 value being documented would be most useful if we could use it to guarantee that all options are documented. That would mean using a complete switch on option/0, effectively mapping each option to its help structure. The simplest and most direct way to print help structures in such a map is to convert the map (which you can get with solutions) into an assoc list sorted on the option. That would require that the function symbols in the option type be listed in the order in which we want their help texts to appear. That is what we should move towards, but we are not there yet. > (Doing this will also make it more likely that the documentation > is updated if the option is changed or deleted.) Yes. But if you want to increase that likelyhood to the maximum, you need to move the help structure either next to, or *into*, the optdef clause. The former would require disabling the option that prevents clauses of different predicates being interleaved. Ideally, it would be disabled only for these two predicates. We don't currently have a way to do that. though it wouldn't be too hard to add that capability. Possibly a new option, --allow-interleaved-clauses="pred1,pred2,pred3,..."? The latter has the problem that an option which has N names has N optdef clauses, not one. We could partly solve that by making the help structure for each alternate name be a value that says "there is no help structure here; get it from the main name xyz". We could even dispense with the alt names field, and instead get the same info from the set of these "pointers". (Though this *would* require automating the addition of "no-" prefixes on negatable option names, since the opt_def clauses *never* have those prefixes.) We could add an int field to the pointers themselves indicating the order in which they should be listed in the help text, since lexicographic order may not always be the one we want. Overall, interleaved clauses seems simpler, and just as good. I don't intend to implement any of these refinements initially. Moving to use just the structure in the initial diff will tell us which of these refinements are actually useful, and we can implement them in lowest to highest hanging fruit order. Zoltan. From zoltan.somogyi at runbox.com Mon May 26 00:05:54 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 26 May 2025 00:05:54 +1000 (AEST) Subject: [m-rev.] for post-commit review: store warning opts in help structures Message-ID: For review by anyone. The log file *is* the subject line. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.opt3 Type: application/octet-stream Size: 38847 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 26 02:05:52 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 26 May 2025 02:05:52 +1000 (AEST) Subject: [m-rev.] for post-commit review: use help structs for verbosity options Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.opt4 Type: application/octet-stream Size: 753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.opt4 Type: application/octet-stream Size: 36361 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 26 03:31:18 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 26 May 2025 03:31:18 +1000 (AEST) Subject: [m-rev.] for post-commit review: convert help for output options Message-ID: For review by anyone. Zoltan. From zoltan.somogyi at runbox.com Mon May 26 04:07:45 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 26 May 2025 04:07:45 +1000 (AEST) Subject: [m-rev.] diff: convert termination and ctgc help to structures Message-ID: This should not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.opt6 Type: application/octet-stream Size: 57 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 26 06:57:00 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 26 May 2025 06:57:00 +1000 (AEST) Subject: [m-rev.] for post-commit review: convert help for compilation model options Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.opt7 Type: application/octet-stream Size: 433 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.opt7 Type: application/octet-stream Size: 54993 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 26 07:52:02 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 26 May 2025 07:52:02 +1000 (AEST) Subject: [m-rev.] for post-commit review: convert codegen options to help structures Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.opt8 Type: application/octet-stream Size: 242 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.opt8 Type: application/octet-stream Size: 22849 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 26 08:39:34 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 26 May 2025 08:39:34 +1000 (AEST) Subject: [m-rev.] diff: convert optimization options to help structures Message-ID: This should not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.opt9 Type: application/octet-stream Size: 161 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.opt9 Type: application/octet-stream Size: 58038 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 26 09:37:15 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 26 May 2025 09:37:15 +1000 (AEST) Subject: [m-rev.] for post-commit review: convert remaining options to help structures Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.opt10 Type: application/octet-stream Size: 50 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Wed May 28 02:26:19 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 28 May 2025 02:26:19 +1000 (AEST) Subject: [m-rev.] diff: improve cohesion and style of style_checks.m Message-ID: This should not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.sc1 Type: application/octet-stream Size: 369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.sc1 Type: application/octet-stream Size: 16513 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Wed May 28 06:30:05 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 28 May 2025 06:30:05 +1000 (AEST) Subject: [m-rev.] for post-commit review: move warnings about non-contiguous clauses to style_checks.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.sc2 Type: application/octet-stream Size: 1154 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.sc2 Type: application/octet-stream Size: 41027 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sat May 31 21:27:05 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 31 May 2025 21:27:05 +1000 (AEST) Subject: [m-rev.] for review: --allow-non-contiguity-for Message-ID: For review by anyone. I will modify user_guide.texi once we agree on the new option's help message. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.ancf Type: application/octet-stream Size: 1605 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.ancf Type: application/octet-stream Size: 44430 bytes Desc: not available URL: