From jfischer at opturion.com Sun Jun 1 14:59:17 2025 From: jfischer at opturion.com (Julien Fischer) Date: Sun, 1 Jun 2025 14:59:17 +1000 Subject: [m-rev.] for review: --allow-non-contiguity-for In-Reply-To: References: Message-ID: On Sat, 31 May 2025 at 21:27, Zoltan Somogyi wrote: > Add the --allow-non-contiguity-for option. > > compiler/options.m: > doc/user_guide.texi: > NEWS.md: > Add an announce the option. > > compiler/style_checks.m: > Parse and check the new options. > > Change how we implement the warn-non-contiguous-{clauses,foreign-procs} > options. Instead of imemediately generating a diagnostic for every immediately ... > diff --git a/compiler/options.m b/compiler/options.m > index 4852c788d..5ab8ce06c 100644 > --- a/compiler/options.m > +++ b/compiler/options.m > @@ -3545,6 +3549,8 @@ long_table("can-fail-function-obsolete-2024-08-10", > compiler_sufficiently_recent). > long_table("unused-statevar-warn-2025-05-16", > compiler_sufficiently_recent). > +long_table("allow-non-contig-for-2025-06-01", > + compiler_sufficiently_recent). > long_table("experiment", experiment). > long_table("experiment1", experiment1). > long_table("experiment2", experiment2). > @@ -4664,6 +4670,15 @@ options_help_warning = Section :- > "Generate a warning if the clauses and foreign_procs of a", > "predicate or function are not contiguous."]), > > + help("allow-non-contiguity-for ", [ > + "Allow the clauses of the named predicates and/or functions", > + "to be intermingled with each other, but not with the clauses", > + "or any other predicates or functions. This option may be", > + "specified more than once, with each option value specifying", > + "a distinct set of predicates and/or function names", > + "that may be intermingled. Each name must uniquely specify", > + "a predicate or a function."]), This should mention that the option also affects foreign_procs. ... > diff --git a/compiler/style_checks.m b/compiler/style_checks.m > index 4493c274a..6cb7d3f54 100644 > --- a/compiler/style_checks.m > +++ b/compiler/style_checks.m ... > @@ -187,6 +202,142 @@ do_we_want_style_warnings(Globals, DoWeWantStyleWarnings) :- ... > +:- pred parse_non_contig_name(predicate_table::in, module_name::in, uint::in, > + string::in, set(pred_id)::in, set(pred_id)::out, > + list(error_spec)::in, list(error_spec)::out) is det. > + > +parse_non_contig_name(PredTable, ModuleName, OptNum, Name, !PredIds, !Specs) :- > + SymName = qualified(ModuleName, Name), > + predicate_table_lookup_sym(PredTable, is_fully_qualified, SymName, > + PredIds), > + ( > + PredIds = [], > + Pieces = > + [words("Error in the"), unth_fixed(OptNum), > + quote("--allow-non-contiguity-for"), words("option:"), > + words("the name")] ++ color_as_subject([quote(Name)]) ++ > + [words("is")] ++ color_as_incorrect([words("uknown.")]) ++ [nl], s/uknown/unknown/ > + Spec = no_ctxt_spec($pred, severity_error, phase_options, Pieces), > + !:Specs = [Spec | !.Specs] > + ; > + PredIds = [PredId], > + set.insert(PredId, !PredIds) > + ; ... > @@ -194,12 +345,23 @@ generate_any_style_warnings(ModuleInfo, WarningsWeWant, !:Specs) :- > PredDeclDefnOrder), > module_info_get_valid_pred_id_set(ModuleInfo, ValidPredIds), > StyleInfo0 = style_info(NonContigDecls, NonContigDefns, PredDeclDefnOrder, > - ValidPredIds, [], [], [], []), > + ValidPredIds, [], [], [], map.init), > module_info_get_pred_id_table(ModuleInfo, PredIdTable), > map.foldl(gather_style_info, PredIdTable, StyleInfo0, StyleInfo), > StyleInfo = style_info(_, _, _, _, ExportedPreds, NonExportedPreds, > - ModeDeclItemNumberSpecs, ClauseGapSpecs), > - !:Specs = ModeDeclItemNumberSpecs ++ ClauseGapSpecs, > + ModeDeclItemNumberSpecs, ClauseGapMap0), > + !:Specs = ModeDeclItemNumberSpecs, > + ( > + NonContigDefns = do_not_warn_non_contiguous_pred_defns > + ; > + NonContigDefns = warn_non_contiguous_pred_defns(_, > + AllowedNonContiguity), > + % ZZZ What's the ZZZ for? > + list.foldl2(report_non_contiguous_clauses_beyond_group(ModuleInfo), > + AllowedNonContiguity, ClauseGapMap0, ClauseGapMap, !Specs), > + map.foldl(report_non_contiguous_clauses(ModuleInfo, []), > + ClauseGapMap, !Specs) > + ), > ( > PredDeclDefnOrder = do_not_warn_pred_decl_vs_defn_order > ; > @@ -476,35 +638,146 @@ maybe_gather_clause_gap_info(PredInfo, ItemNumbers, !StyleInfo) :- > % *if and only if* that malformed clause would cause a gap > % in the item number sequence. > then > - Spec = report_non_contiguous_clauses(PredInfo, > - FirstRegion, SecondRegion, LaterRegions), > - ClauseGapSpecs0 = !.StyleInfo ^ style_clause_gap_specs, > - ClauseGapSpecs = [Spec | ClauseGapSpecs0], > - !StyleInfo ^ style_clause_gap_specs := ClauseGapSpecs > + GapMap0 = !.StyleInfo ^ style_clause_gaps, > + map.det_insert(PredId, RegionsWithGaps, GapMap0, GapMap), > + !StyleInfo ^ style_clause_gaps := GapMap > + % ZZZ Likewise. > + % Spec = report_non_contiguous_clauses(PredInfo, RegionsWithGaps), > + % ClauseGapSpecs0 = !.StyleInfo ^ style_clause_gap_specs, > + % ClauseGapSpecs = [Spec | ClauseGapSpecs0], > + % !StyleInfo ^ style_clause_gap_specs := ClauseGapSpecs > else > true That looks fine otherwise. Julien. From zoltan.somogyi at runbox.com Sun Jun 1 17:14:35 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 01 Jun 2025 17:14:35 +1000 (AEST) Subject: [m-rev.] for review: --allow-non-contiguity-for In-Reply-To: References: Message-ID: On Sun, 1 Jun 2025 14:59:17 +1000, Julien Fischer wrote: > > @@ -194,12 +345,23 @@ generate_any_style_warnings(ModuleInfo, WarningsWeWant, !:Specs) :- > > PredDeclDefnOrder), > > module_info_get_valid_pred_id_set(ModuleInfo, ValidPredIds), > > StyleInfo0 = style_info(NonContigDecls, NonContigDefns, PredDeclDefnOrder, > > - ValidPredIds, [], [], [], []), > > + ValidPredIds, [], [], [], map.init), > > module_info_get_pred_id_table(ModuleInfo, PredIdTable), > > map.foldl(gather_style_info, PredIdTable, StyleInfo0, StyleInfo), > > StyleInfo = style_info(_, _, _, _, ExportedPreds, NonExportedPreds, > > - ModeDeclItemNumberSpecs, ClauseGapSpecs), > > - !:Specs = ModeDeclItemNumberSpecs ++ ClauseGapSpecs, > > + ModeDeclItemNumberSpecs, ClauseGapMap0), > > + !:Specs = ModeDeclItemNumberSpecs, > > + ( > > + NonContigDefns = do_not_warn_non_contiguous_pred_defns > > + ; > > + NonContigDefns = warn_non_contiguous_pred_defns(_, > > + AllowedNonContiguity), > > + % ZZZ > > What's the ZZZ for? A reminder to add a comment, which I have now done. > > @@ -476,35 +638,146 @@ maybe_gather_clause_gap_info(PredInfo, ItemNumbers, !StyleInfo) :- > > % *if and only if* that malformed clause would cause a gap > > % in the item number sequence. > > then > > - Spec = report_non_contiguous_clauses(PredInfo, > > - FirstRegion, SecondRegion, LaterRegions), > > - ClauseGapSpecs0 = !.StyleInfo ^ style_clause_gap_specs, > > - ClauseGapSpecs = [Spec | ClauseGapSpecs0], > > - !StyleInfo ^ style_clause_gap_specs := ClauseGapSpecs > > + GapMap0 = !.StyleInfo ^ style_clause_gaps, > > + map.det_insert(PredId, RegionsWithGaps, GapMap0, GapMap), > > + !StyleInfo ^ style_clause_gaps := GapMap > > + % ZZZ > > Likewise. That was a reminder to delete the following commented out code if it turned out not to be needed. I deleted it. > That looks fine otherwise. Thank you. I followed all your other suggestions as well. Zoltan. From zoltan.somogyi at runbox.com Mon Jun 2 08:15:33 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 02 Jun 2025 08:15:33 +1000 (AEST) Subject: [m-rev.] for review: proposed reclassification of options Message-ID: The first attached file is an extract from the current options.m. The second is that same file with additions outlining the changes I am proposing to make. The third is the diff between them. I am proposing some new option categories and subcategories, which I hope the attached file defines adequately. I am also proposing to reclassify many options, some into the new categories, some into existing ones, and in two cases, I am proposing that what are now warnings should become errors, which cannot be switched off by options (so the options can be deleted). I am posting this proposal in this form, because a fully implemented proposal would also include moving the affected option's help text, which would be unhelpful clutter in the diff. For review by everyone, mostly because I am not sure about the intended limitations on the use of some options. Specifically, I am not clear about which otherwise-internal-use-only options are actually expected to be used by programmers when doing cross-compilation. I am therefore also not sure whether it would be worth creating a new option category, with associated new section in the help text (and the user guide) specifically for such options. In the absence of a review, or a promise of one, in the next 24 hours, I will assume that noone has any objections to the proposal, and will then construct and commit the full version. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: OPTDEF0.gz Type: application/x-gzip Size: 8994 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OPTDEF.gz Type: application/x-gzip Size: 9728 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OPTDEF.diff.gz Type: application/x-gzip Size: 3880 bytes Desc: not available URL: From jfischer at opturion.com Mon Jun 2 23:21:34 2025 From: jfischer at opturion.com (Julien Fischer) Date: Mon, 2 Jun 2025 23:21:34 +1000 Subject: [m-rev.] for review: proposed reclassification of options In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 at 08:15, Zoltan Somogyi wrote: > > The first attached file is an extract from the current options.m. > The second is that same file with additions outlining the changes > I am proposing to make. The third is the diff between them. > > I am proposing some new option categories and subcategories, > which I hope the attached file defines adequately. I am also > proposing to reclassify many options, some into the new > categories, some into existing ones, and in two cases, I am proposing > that what are now warnings should become errors, which cannot be > switched off by options (so the options can be deleted). > > I am posting this proposal in this form, because a fully implemented > proposal would also include moving the affected option's help text, > which would be unhelpful clutter in the diff. > > For review by everyone, mostly because I am not sure about the > intended limitations on the use of some options. Specifically, > I am not clear about which otherwise-internal-use-only options > are actually expected to be used by programmers when doing > cross-compilation. I am therefore also not sure whether it would > be worth creating a new option category, with associated new section > in the help text (and the user guide) specifically for such options. > > In the absence of a review, or a promise of one, in the next 24 hours, > I will assume that noone has any objections to the proposal, and > will then construct and commit the full version. That looks reasonable to me, with one comment below. > --- OPTDEF0 2025-06-01 19:44:15.000000000 +1000 > +++ OPTDEF 2025-06-02 06:40:26.000000000 +1000 ... > @@ -871,25 +897,31 @@ > optdef(oc_misc, filenames_from_stdin, bool(no)). > optdef(oc_misc, typecheck_ambiguity_warn_limit, int(50)). > optdef(oc_misc, typecheck_ambiguity_error_limit, int(3000)). > -optdef(oc_misc, help, bool(no)). > +make oc_help a new category, the first, containing just this option > + because it should be listed first, in a section of its own > +optdef(oc_misc, help, bool(no)). => oc_help > optdef(oc_misc, version, bool(no)). > optdef(oc_misc, target_arch, string("")). > +% Should we have a section containing this option, and all the others > +% that are useful ONLY when cross compiling? > optdef(oc_misc, cross_compiling, bool(no)). The cross_compiling option no longer does anything and is no longer documented. Depending on when it was undocumented, it can probably be removed. All of the other "cross compilation" options are also config options. (Currently, the way to set up a Mercury cross compiler is by setting the values in the configuration script as per tools/configure_cross.) Julien. From zoltan.somogyi at runbox.com Tue Jun 3 07:58:21 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 03 Jun 2025 07:58:21 +1000 (AEST) Subject: [m-rev.] diff: delete the warn_{missing, wrong}_module_name options Message-ID: The concept has been agreed, and the implementation is straightforward. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.wmn Type: application/octet-stream Size: 1339 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.wmn Type: application/octet-stream Size: 14539 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Tue Jun 3 18:47:11 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 03 Jun 2025 18:47:11 +1000 (AEST) Subject: [m-rev.] for review: proposed reclassification of options In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 23:21:34 +1000, Julien Fischer wrote: > On Mon, 2 Jun 2025 at 08:15, Zoltan Somogyi wrote: > > In the absence of a review, or a promise of one, in the next 24 hours, > > I will assume that noone has any objections to the proposal, and > > will then construct and commit the full version. > > That looks reasonable to me, with one comment below. The attached comment does what was agreed. > The cross_compiling option no longer does anything and is no longer documented. > Depending on when it was undocumented, it can probably be removed. What is the dependence? > All of the other "cross compilation" options are also config options. > (Currently, the way to set up a Mercury cross compiler is by > setting the values in the configuration script as per tools/configure_cross.) I added a comment to this effect. Thanks for the review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.oc Type: application/octet-stream Size: 108 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.oc Type: application/octet-stream Size: 33243 bytes Desc: not available URL: From jfischer at opturion.com Tue Jun 3 19:06:55 2025 From: jfischer at opturion.com (Julien Fischer) Date: Tue, 3 Jun 2025 19:06:55 +1000 Subject: [m-rev.] for review: proposed reclassification of options In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 at 18:47, Zoltan Somogyi wrote: > > > The cross_compiling option no longer does anything and is no longer documented. > > Depending on when it was undocumented, it can probably be removed. > > What is the dependence? If it was removed recently, we may want to keep it about for a bit in order to prevent breaking existing Mmakefile / options files (if there are any that use it). Julien. From zoltan.somogyi at runbox.com Tue Jun 3 19:39:29 2025 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 03 Jun 2025 19:39:29 +1000 (AEST) Subject: [m-rev.] for review: proposed reclassification of options In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 19:06:55 +1000, Julien Fischer wrote: > On Tue, 3 Jun 2025 at 18:47, Zoltan Somogyi wrote: > > > > > > The cross_compiling option no longer does anything and is no longer documented. > > > Depending on when it was undocumented, it can probably be removed. > > > > What is the dependence? > > If it was removed recently, we may want to keep it about for a bit in order to > prevent breaking existing Mmakefile / options files (if there are any > that use it). Commit a65336fad2697cd2650a8e7d29fff8e2a8c33f7d by Peter commented out the help text of --cross-compiling in options.m. As far as I can tell, that help text was never included in user_guide.texi in the first place. Since commit a65336fad2697cd2650a8e7d29fff8e2a8c33f7d was in 2015 march, I think it is ready to be removed. Agreed? Zoltan. From jfischer at opturion.com Tue Jun 3 19:41:52 2025 From: jfischer at opturion.com (Julien Fischer) Date: Tue, 3 Jun 2025 19:41:52 +1000 Subject: [m-rev.] for review: proposed reclassification of options In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 at 19:39, Zoltan Somogyi wrote: > > On Tue, 3 Jun 2025 19:06:55 +1000, Julien Fischer wrote: > > > On Tue, 3 Jun 2025 at 18:47, Zoltan Somogyi wrote: > > > > > > > > > The cross_compiling option no longer does anything and is no longer documented. > > > > Depending on when it was undocumented, it can probably be removed. > > > > > > What is the dependence? > > > > If it was removed recently, we may want to keep it about for a bit in order to > > prevent breaking existing Mmakefile / options files (if there are any > > that use it). > > Commit a65336fad2697cd2650a8e7d29fff8e2a8c33f7d by Peter > commented out the help text of --cross-compiling in options.m. > As far as I can tell, that help text was never included in user_guide.texi > in the first place. > > Since commit a65336fad2697cd2650a8e7d29fff8e2a8c33f7d was in 2015 march, > I think it is ready to be removed. Agreed? If it was that long ago, then yes, it should be removed. Julien.