--no-ansi (mgnuc) and --no-ansi-c (mmc) have not actually done anything for
many years now. Deprecate these options and remove their "use" throughout most
of the Mercury system. (The remaining uses are in the Makefiles for the Boehm
GC, which need to be updated separately.)
Also deprecate the internal compiler option --cflags-for-ansi.
compiler/options.m:
Document that --no-ansi-c is now deprecated.
Document that the internal option --cflags-for-ansi is now
deprecated.
compiler/compile_target_code.m:
Do not pass the ANSI options to the C compiler.
scripts/mgnuc.in:
scripts/mgnuc_file_opts.sh-subr:
Deprecate the --no-ansi option; delete code that no longer does
anything useful.
configure.ac:
Delete the configuration variable CFLAGS_FOR_ANSI; it is only ever
set to be empty. (The comment talks about --no-ansi doing other things
in the mgnuc script. It used to also cause some preprocessor macros
to be defined for compatibility with the system headers on some
platforms -- that has not been the case since 2013.)
doc/user_guide.texi:
Document that --no-ansi-c is deprecated.
bytecode/Mmakefile:
compiler/Mercury.options:
library/Mercury.options:
extras/odbc/odbc.m:
runtime/Mmakefile:
scripts/Mercury.config.bootstrap.in:
scripts/Mercury.config.in:
tests/hard_coded/Mercury.options:
tests/valid/Mercury.options:
trace/Mmakefile:
util/Mmakefile:
Conform to the above change.
NEWS.md:
Announce the above.
The reason for this is that without such limits,
- the generation of a HLDS dump for the valid/inst_perf_bug_2 test case
takes almost forever, and
- generates a multi-gigabyte HLDS dump, which causes e.g. vim to take
forever to open.
Making the generation and use of HLDS dumps practical is worth the cost
of losing some information. (Information you can't afford to generate
or to use is lost anyway.)
compiler/options.m:
doc/user_guide.texi.m:
Add a new option to limit the size of the insts we output
in the inst tables part of HLDS dumps. This option should allow users
to select the tradeoff between the amount of information being preserved
and the cost of generating/using that information.
compiler/hlds_out_module.m:
Pass the value of the new option to hlds_out_inst_table.m.
compiler/hlds_out_inst_table.m:
Specify the size limit when writing out insts as either the keys or
the values in the various kinds of inst tables.
compiler/parse_tree_to_term.m:
To implement those limits, add inst_to_limited_size_term and
inst_name_to_limited_size_term, versions of the old inst_to_term
and inst_name_to_term functions that truncate the given inst or inst name
at the given "size" if necessary. The measure of "size" is just
function symbols in the resulting term in most cases, though
we treat things that in practice never get too big, such as types,
as "one", regardless of the number of function symbols they contain.
To make the parallel between the old non-size-limiting and the new
size-limiting versions of the relevant codes easier to see, transform
the functions in the old code to predicates. (The new versions have
to be predicates to allow the size to be passed along in a state var.)
compiler/hlds_out_goal.m:
When we print out the argument modes of a unification, limit the depth
to which we write out the various insts to three. This should be
more than enough, because any inst that we now replace with "..."
should be available in the mode information of the atomic goal that
generates it, whether that goal is a unification or a call.
We generate the debugger documentation files, e.g. the command list, by
processing the output of the info tool and running through a series of sh and
awk scripts. This is breaking builds for MSYS based systems on Windows because
the port of awk there does not handle non-ASCII characters and info will
sometimes output those. Using the C locale on affected systems causes the
output of info to be ASCII.
doc/generate_mdb_doc:
Force the use of the C locale on MSYS / MinGW systems in order to avoid
problems with awk.
Shut up some warnings form shellcheck.
compiler/op_mode.m:
Add a field that specifies whether the compiler was invoked by
"mmc --make" to the opm_top_args top-level op_mode. This is the
class of op_modes for which we need that info.
Fill in this new field from the value of the --invoked-by-mmc-make
option.
compiler/options.m:
Add an "only_opmode_" prefix to the internal name of the
--invoked-by-mmc-make option. Move this option next to the --make option.
Improve the wording of some options' usage messages.
doc/user_guide.texi:
Make the same changes in wording here as well.
compiler/add_pragma.m:
compiler/add_type.m:
compiler/exception_analysis.m:
compiler/handle_options.m:
compiler/headvar_names.m:
compiler/hlds_module.m:
compiler/mercury_compile_main.m:
compiler/mercury_compile_make_hlds.m:
compiler/mode_errors.m:
compiler/op_mode.m:
compiler/options.m:
compiler/post_term_analysis.m:
compiler/post_typecheck.m:
compiler/structure_reuse.analysis.m:
compiler/structure_reuse.versions.m:
compiler/structure_sharing.analysis.m:
compiler/tabling_analysis.m:
compiler/term_util.m:
compiler/trailing_analysis.m:
compiler/unused_args.m:
Conform to the changes above, either by finding out whether
the compiler was invoked by mmc --make using the op_mode instead
of the option, or by ignoring that info where not needed.
docs/reference_manual.texi:
docs/user_guide.texi:
As above (and check that they are still current).
doc/mercury.html.in:
Update a link to the old Mercury homepage.
Update the markup style.
This option lets the user provide a file containing information to
remove some edges from the trans-opt dependency graph, i.e. the graph
used to determine which .trans_opt files to read when making a module's
own .trans_opt file.
The reason to remove edges from the graph is to break dependency cycles.
.trans_opt files for modules within an SCC have to be made one after
another, instead of in parallel. For example, the standard library
contains one large SCC due to circular imports, so making .trans_opt
files turns out to be a bottleneck when building the standard library
(on a machine with sufficient parallelism available).
Furthermore, the user had no control over which modules in an SCC
could read the .trans_opt files of other modules in the same SCC.
If a and b happened to import each other, the compiler would always
break the cycle by allowing a to read b.trans_opt, but not allow b to
read a.trans_opt, simply based on module names. The new option lets the
user break the cycle in a way that may improve analysis results.
compiler/options.m:
Add the --trans-opt-deps-spec option.
compiler/generate_dep_d_files.m:
If the option --trans-opt-deps-spec FILE is used, use the
information given in the file to remove some edges from the
trans-opt dependency graph.
If --generate-module-order is passed, also output the module order
computed from the trans-opt dependency graph to a file.
Users may find this a useful starting point when writing their own
spec file.
compiler/write_deps_file.m:
Add a field to intermod_deps to hold the (user-adjusted)
trans-opt dependencies.
Add a type, maybe_include_trans_opt_rule, to indicate whether or not
to include a trans_opt_deps rule in a mmake dependency file.
Separate the case when a trans_opt_deps rule is to be written,
indicating where the dependencies come from.
When automatically rewriting a .d file after producing target code,
etc., write the trans_opt_deps rule with the same list of dependencies
as the old .d file.
compiler/mercury_compile_make_hlds.m:
Conform to maybe_include_trans_opt_rule change.
Rename some variables for clarity.
Rename mmc and mgnuc options that set this grade component to --c-debug-grade.
Let the options named --c-debug of both mmc and mgnuc enable C level debugging
of only the module being compiled.
runtime/mercury_grade.h:
Rename the .ll_debug grade component to .c_debug. Also rename the C macro
that controls the presence or absence of this grade component
from MR_LL_DEBUG to MR_C_DEBUG_GRADE.
runtime/mercury_conf_param.h:
runtime/mercury_debug.c:
runtime/mercury_debug.h:
runtime/mercury_engine.c:
runtime/mercury_label.c:
runtime/mercury_memory_zones.c:
runtime/mercury_memory_zones.h:
runtime/mercury_overflow.c:
runtime/mercury_std.h:
runtime/mercury_wrapper.c:
Rename the MR_LOWLEVEL_DEBUG macro to MR_DEBUG_THE_RUNTIME.
Previously, the name of this macro wrongly implied that it had
something to do with the old .ll_debug grade component, even though
- the MR_LOWLEVEL_DEBUG macro was designed to debug LLDS grades,
since only these existed when it was created, while
- the .ll_debug grade component (now .c_debug) is useful only for
MLDS grades targeting C.
compiler/options.m:
Rename the old confusingly named low_level_debug option to c_debug_grade.
Move it to the list of grade options, and fix its documentation, which
was completely wrong:
- code in compile_target_code.m treated it as being a synonym of
the .ll_debug (now .c_debug) grade component, while
- its (commented out) documentation here in options.m said it called for
the enabling of what is now MR_DEBUG_THE_RUNTIME.
compiler/compile_target_code.m:
Conform to the rename just above.
Define MR_C_DEBUG_GRADE instead of MR_LL_DEBUG if c_debug_grade is enabled.
Pass -g to the C compiler if either c_debug_grade or target_debug
is enabled.
Add an XXX about a missing safety check for an obsolete experimental
feature.
compiler/compute_grade.m:
When given a grade with a .c_debug grade component, set only the
c_debug_grade option; don't set the target_debug option, which is NOT
a grade option. The change to compile_target_code.m above handles the
only situation in which this implication was formerly required.
scripts/canonical_grade.sh-subr:
scripts/init_grade_options.sh-subr:
scripts/parse_grade_options.sh-subr:
Look for and process the .c_debug grade component instead of .ll_debug.
Use a sh variable named c_debug_grade to record its absence/presence.
Look for and process the --c-debug-grade grade-component option,
setting the same sh variable, c_debug_grade. (All grade components
can be set piecemeal using sh options to the scripts using these
subroutines.) This replaces the old, confusingly named option
--low-level-debug.
scripts/mgnuc.in:
scripts/mgnuc_file_opts.sh-subr:
Consistently use the sh variable c_debug to record the presence of
the (non-grade) --c-debug option to mgnuc, and the sh variable
c_debug_grade to record the presence of the .c_debug grade component.
Stop looking for and handling the --low-level-debug option, which
mgnuc used to document, even though this duplicated the same documentation
in init_grade_options.sh-subr, which mgnuc includes. The difference was
that init_grade_options.sh-subr meant it to represent the old .ll_debug
MLDS grade component, while mgnuc treated it as specifying what is now
MR_DEBUG_THE_RUNTIME for LLDS grades. It didn't help that two sh variables
with quite different semantics had names that differed only in an
underscore: LLDEBUG_OPTS vs LL_DEBUG_OPTS.
scripts/Mmakefile:
Add a missing dependency to force the rebuild of mgnuc after each update
of its sh subroutine mgnuc_file_ops.sh-subr.
doc/user_guide.texi:
Document the --c-debug-grade option of mmc. This option was not publicly
documented under its original misleading name (--low-level-debug), but
its documentation is now possible without contorted dancing around the
name.
Clarify the documentation of mgnuc's --c-debug option.
README.sanitizers:
configure.ac:
Conform to the rename of the grade component.
grade_lib/grade_spec.m:
grade_lib/grade_string.m:
grade_lib/grade_structure.m:
grade_lib/try_all_grade_structs.m:
Conform to the rename of the grade component .ll_debug to .c_debug.
Don't allow the .c_debug grade component in LLDS grades.
In grade_string.m, add some obvious implications of some grade components.
grade_lib/choose_grade.m:
grade_lib/grade_lib.m:
grade_lib/test_grades.m:
grade_lib/var_value_names.m:
Fix white space.
scripts/ml.in:
tools/lmc.in:
tools/test_mercury:
Conform to the change in compile_target_code.m to the naming of
Boehm gc library variants.
library/ops.m:
Add these to the list of operators, at the same priority as << and >>.
library/mercury_term_lexer.m:
<<u and >>u are the first operators that combine graphic characters with
alphanumeric characters. This requires extending the lexer, because
if the lexer, when given e.g. the string "<<u", returns "<<" and "u"
as separate tokens, then the presence of <<u in the ops table
would not matter.
Implement this special case in all three different variants of the lexer.
doc/reference_manual.texi:
Document the new operators, and their special-case nature.
doc/reference_manual.texi:
Clarify how the module qualification operator interacts with
other operators.
Extend the definition of "principal functor" to module-qualified
terms.
Define "fully qualified" prior to use.
State the requirements on module qualification _after_ describing
use_module.
doc/reference_manual.texi:
In the description of mode-determinism assertions, point readers
to the strict sequential semantics to disable optimizations
derived from those assertions.
In Exception handling, provide an example where the behaviour
depends on the choice of operational semantics. Show one way to
rewrite the example to make it work with any operational semantics.
In Formal semantics, define predicate strictness, and be more
expansive on the options that determine the operational semantics
to be used.
In Trace goals, mention the effect of non-fully-strict semantics
on calls to predicates containing trace goals.
When specified, this option causes the compiler to output,
to <module>.local_call_tree, a flattened form of the part of the
module call tree restricted to local predicates and functions, like this:
pred polymorphism_process_module/5
pred maybe_polymorphism_process_pred/7
pred polymorphism_update_arg_types/5
pred maybe_polymorphism_process_pred/7
pred polymorphism_process_pred_msg/7
pred polymorphism_process_pred_msg/7
pred polymorphism_process_pred/6
pred polymorphism_process_pred/6
pred polymorphism_process_clause_info/6
pred add_extra_arg_modes_to_proc/3
This output consists of a list of entries, with each entry naming
a predicate or function, and listing all the local predicates and functions
it calls. Both the callees in a single entry and the entries themselves
are in the order in which a depth-first left-to-right traversal of the
module, starting at the exported predicates and functions, would encounter
them. That order is also output to <module>.local_call_tree_order.
This information can give useful guidance about how the contents
of a module should be ordered.
doc/user_guide.texi:
compiler/options.m:
As above.
NEWS:
Announce the new option.
compiler/hlds_call_tree.m:
A new module to implement the new option.
compiler/hlds.m:
compiler/notes/compiler_design.html:
Add and document the new module.
compiler/mercury_compile_front_end.m:
Invoke the new module if the new option is set.
compiler/hlds_desc.m:
Add describe_pred and describe_pred_from_id. Reimplement
describe_proc and describe_proc_from_id in terms of those.
Allow callers of all four to decide whether we want the descriptions
to include the names of the defining module.
compiler/dead_proc_elim.m:
compiler/ml_proc_gen.m:
compiler/proc_gen.m:
Conform to the change to hlds_desc.m.
compiler/hlds_goal.m:
Document when it is ok for traversals of goals to assume that
they won't find any rhs_lambda_goals or complicated_unifys
in unifications.
Change the documentation of the five classes of unifications
(construct/deconstruct/assign/simple_test/complicated_unify)
to refer to the LHS as X and the RHS as Y, since pretty much
all the modules focusing on unifications (such as superhomoneous.m)
use that naming convention. Having the opposite convention here
was not a good idea.
compiler/prog_data.m:
Fix comment rot.
doc/reference_manual.texi:
NEWS:
Document and announce the new pragma.
compiler/prog_data_pragma.m:
compiler/prog_item.m:
Provide a representation for the new pragma. The part that ends up
being referred to from the HLDS goes into prog_data_pragma.m,
the part that is not needed once the HLDS has been constructed
goes into prog_item.m.
compiler/hlds_pred.m:
Add a slot to pred_infos for info from the new pragma.
Fix a bug in the comment on marker_has_format_call.
compiler/add_pragma.m:
Add the information in these pragmas to the HLDS.
compiler/check_pragma_format_call.m:
A new module to check the validity of format_call pragmas.
These checks test whether the arguments named in such pragmas
have the expected types and modes, which means that
the check must be done after both type and mode checking.
compiler/check_hlds.m:
compiler/notes/compiler_design.html:
Add and document the new module.
compiler/hlds_module.m:
Add a field to the module_info that records the set of pred_ids
that have format_call pragmas.
compiler/mercury_compile_front_end.m:
Invoke the check_pragma_format_call pass *provided* that
the new field in the module_info says it has any pragmas to check.
compiler/parse_pragma.m:
Add code to parse the new pragma.
compiler/format_call.m:
Check calls to predicates and functions with the new pragma
the same way as we check calls to string.format, io.format,
and stream.string_writer.format.
This required separating the code that checked calls to such predicates
from the code that optimized calls to such predicates, since
- a predicate or function with a format_call pragma that specifies
more than one argument pair has to have its correctness checked
for each pair, and
- a predicate or function with a format_call pragma does not actually
do any formatting, so that formatting cannot be optimized.
Fix an old bug, where we included the function result in the function's
reported arity, which meant that an error message could mention a call
to a nonexistent function. As part of that fix, the error message
now specifies whether it is complaining about a call to a predicate
or a function.
Change the exported interface of this module a bit
in order to allow the factoring out of repeated code.
compiler/parse_string_format.m:
Separate the parsing of format strings from their optimization,
again because calls to predicates and functions with format_call
pragmas need to be checked but cannot be optimized.
compiler/polymorphism.m:
Record the effect on argument numbers of any type_info and/or
typeclass_info arguments added by this pass.
compiler/convert_parse_tree.m:
compiler/det_analysis.m:
compiler/direct_arg_in_out.m:
compiler/equiv_type.m:
compiler/get_dependencies.m:
compiler/hlds_out_pred.m:
compiler/item_util.m:
compiler/module_qual.qualify_items.m:
compiler/parse_tree_out_pragma.m:
compiler/prog_item_stats.m:
compiler/recompilation.version.m:
compiler/simplify_proc.m:
Conform to the changes above.
tests/invalid/bad_format_call.{m,err_exp}:
A new test case to see whether check_pragma_format_call.m detects
and reports invalid format_call pragmas as expected.
tests/warnings/format_call_warning.{m,exp}:
tests/warnings/format_call_warning_helper.m:
A new test case to see whether we generate the expected set of error
messages for incorrect calls to a predicate with a format_call pragma.
tests/invalid/Mmakefile:
tests/warnings/Mercury.options:
tests/warnings/Mmakefile:
Enable the new test cases.
tests/invalid/string_format_bad.err_exp:
tests/invalid/string_format_unknown.err_exp:
tests/warnings/disabled_warning.exp:
Expect the predicate vs function distinction to the printed in
error messages about bad calls to formatting predicates and functions.
There are three main aims for this change:
1. Don't rely so much on users having knowledge of Prolog (ideally we
wouldn't require it at all, but this change probably doesn't fully achieve
that). Present the information more linearly, i.e., without requiring
so many forward references.
2. Make important information less likely to be overlooked. As it stands,
we give a lot of semantics in the Syntax chapter where users wouldn't
expect to find it (they're more likely to just skim over such a chapter).
3. Remove some inconsistencies in our descriptions and use of terminology,
and try to remove ambiguities.
Changes to terminology
----------------------
These are aimed at being more consistent, as well as dividing things up
into concepts that we need to refer to later on.
- A term is now a core term or a special term. The latter are for list
syntax, etc. Avoid the use of "is parsed as", the significance of which
is not clear, and instead define an equivalence relation via a term
normalization procedure.
- Define "functor" and "principal functor". Don't use "functor" to talk
about terms: the functor is defined as the name/arity pair. Also give
some synonyms we use for functor.
- Core terms are divided into variables, constants, and functor terms.
Functor terms are names on their own or names with arguments
(i.e., "functor terms" are those terms that have meaningful functors).
- "Higher-order terms" are now called "apply terms", since they aren't
necessarily higher-order themselves, and because that is a semantic
concept anyway.
- Data-terms are now referred to as expressions.
- Refer to "field access" rather than "record syntax". It's not made clear
that these are referring to the same feature, so it's better to stick to
one term (at least until full definitions are given).
Changes to document structure
-----------------------------
The Syntax chapter as a whole has been split into two chapters,
Syntax and Clauses. The new structure is as follows:
Syntax
- Additional sections are added for comments and line number directives.
- The Tokens section is split into token types (so that, e.g., variables
can be looked up quickly).
- "Operators" covers everything about operator syntax, not just builtin
operators.
- "Terms" covers the material previously in that section. It adds a summary
in the form of grammar rules (but makes it clear all the information is
also in the prose), and a term normalization procedure that is _not_
written in pseudo-Mercury. The grammar is there for people who are likely
to skip the prose but less likely to skip a grammar, and the prose is there
because that's the best way to describe things.
- "Items" covers the material previously in "Items", "Declarations",
"Facts", and "Rules".
Clauses
- Added an overview of Mercury semantics.
- "Goals" covers the same material as before, but I have rearranged the
order of the goals so as to avoid forward references, and to put more
commonly used goals earlier.
- "Expressions" covers the material previously in "Data-terms" and its
subsections. The expressions are (mostly) collected into one table, but
field access expressions are kept separate as they require a bit more
explanation. I've used an anchor on this separate bit, however, so maybe
it should be in a section that follows Expressions (i.e., Expressions
should say "see next section for details" or whatever).
- "State variables", "Variable scoping", "Implicit quantifiaction", and
"Elimination of double negation" are kept largely as is.
- "Definite Clause Grammars" is added which collects all the information
relating to DCGs.
Other changes
-------------
- Names now include sequences of graphic chars and a single semicolon,
which is what our parser actually allows.
- Use hyphens in meta-variables rather than underscore, per the texinfo
guidelines.
- Explain that operators are a syntactic concept and you need to import
a module to get, e.g., arithmetic operations. Point out the user defined
operator in the prose rather than in a footnote. And fix the formatting
of that table!
- Try to use a more consistent writing style.
The usual mdb "dump" command puts every function symbol on its own line.
This guarantees that we generate any line that is too long to be displayed
on terminals, but it also generates output that is too stretched out
vertically for its structure to be readily apparent. Dumping the term
as a doc allows pretty_printer.m to put as many function symbols on a line
as would fit, without exceeding the maximum line length.
browser/browse.m:
Add save_term_to_file_doc, a way to save a (possibly synthetic)
browser term in a file, using an interface that works the same way
the predicate that saves browser terms as XML.
Inline a predicate at its only call site. Improve variable names.
trace/mercury_trace_browse.[ch]:
Add MR_trace_save_term_as_doc, as an interface function between
save_term_to_file_doc and the code of mercury_trace_cmd_browsing.c.
trace/mercury_trace_cmd_browsing.c:
Add support for a new -p/--prettyprint flag to the mdb "dump" command,
which asks for the given term to be dumped as a pretty_printer doc.
doc/user_guide.texi:
NEWS:
Document the new option.
library/pretty_printer.m:
NEWS:
Rename write_as_doc to write_doc_formatted, and fix its argument type.
tests/debugger/browser_test.inp:
Dump a term that we already dumped with "dump" with "dump -x" and
"dump -p" as well.
tests/debugger/browser_test.m:
Put the code to remove the files we are going to dump to
and then later to print the files we have dumped to into separate
predicates. This keeps most (but not all) line numbers unchanged
even though we now dump to more files.
tests/debugger/browser_test.exp3:
Update this file to account both for the extra output from the just-added
dump commands, and for the changes in line numbers.
doc/reference_manual.texi:
NEWS:
Allow a disable_warning scope to override the setting of the
--warn-unknown-format-calls option to "yes" inside its scope.
compiler/prog_data.m:
Provide a representation for the new kind of disable-able warning.
compiler/parse_goal.m:
Parse the new kind of disable-able warning.
compiler/prog_out.m:
Print out the new kind of disable-able warning.
compiler/format_call.m:
Add a parameter to the format checking code to control whether
we generate this warning. Using this parameter yields clearer code
that locally overriding the value of the option.
compiler/simplify_goal_scope.m:
Ignore the new kind of disable-able warning in code that has nothing
to do with it.
compiler/options.m:
doc/user_guide.texi:
Fix an old issue: include stream.string_writer.format in the description
of --warn-unknown-format-calls.
tests/warnings/disabled_warning.{m,exp}:
Add a test of the new functionality.
tests/warnings/Mmakefile:
tests/warnings/Mercury.options:
Enable the new test case.
The new option is on by default, and it generates a warning about pragmas
that specify a name/arity pair that matches both a predicate and a function,
but does not say which one it is intended to apply to.
compiler/options.m:
doc/user_guide.texi:
Add the new option.
NEWS:
Announce the new option.
compiler/add_pragma.m:
Implement the new option.
Move to one predicate, get_matching_pred_ids, the code for dealing with
both the absence of any matches, and the presence of more than one match,
when looking up name/arity pairs in the predicate table. This allows us
to delete the mostly-duplicate code fragments that did the same thing
in all of get_matching_pred_ids's callers.
Simplify the handling of conflicts between marker pragmas.
compiler/hlds_pred.m:
Separate out no_inline decisions made by the compiler itself from
the similar decisions made by users, in order to allow that simplification.
Move the two inline markers next to each other.
compiler/make_hlds_error.m:
Change a predicate called from add_pragma*.m to take user arities
in their semantic form, not their int form, which raises the level
of the predicate's interface, and factors out duplicate code in its
callers.
compiler/add_pragma_type_spec.m:
compiler/intermod.m:
compiler/table_gen.m:
Conform to the changes above.
doc/reference_manual.texi:
Document pred(...) and func(...) wrappers around name/arity pairs
in pragmas.
Delete the commented out section on reserve_tag pragmas, which were
deleted a while ago.
tests/invalid/inline_conflict.m:
Expand this test case to test the *absence* of a warning for an
ambiguous pragma with --no-warn-ambiguous-pragma.
tests/invalid/inline_conflict_warn.{m,err_exp}:
tests/invalid/Mercury.options:
Add a copy of the inline_conflict test case to test the presence of
a warning for an actually ambiguous pragma.
tests/invalid_nodepend/fact_table_in_interface.err_exp:
Expect the updated wording of a warning.
Add new options that allow Java runtime flags to be set in the launcher scripts
we generate for executables in the Java grade.
compiler/options.m:
Add two new options: --java-runtime-flags and --java-runtime-flag
that can be used to embed flags for the Java interpreter in the
launcher scripts we generate for Java grade executables.
Add --javac-flags and --javac-flag as synonyms for --java-flags
and --java-flag respectively.
Rename the corresponding values of the option/0 type to
java_compiler_flags and quoted_java_compiler_flag respectively.
Extend the documentation of --java-classpath to say that it also
affects the Java launcher scripts.
compiler/module_cmds.m:
Include any user-specified Java runtime flags in the launcher
scripts.
compiler/compile_target_code.m:
Conform to the above change.
doc/user_guide.texi:
Document the above option changes and additions.
Document how the launcher scripts interact with with the new
options and also with --java-classpath.
NEWS:
Announce the above changes.
trace/mercury_trace_cmd_developer.c:
trace/mercury_trace_tables.[ch]:
Add two options to the mdb command "ambiguity".
Print ambiguities between function and predicate forms of the same
operation, such as list.length, only if the new option -b, or
--both-pred-and-func, is given.
Print ambiguities involving procedures that were created by type
specialization only if the new option -s, or --typespec is given.
(The -t option name was already taken.)
These changes remove from the ambiguity command's output
(some of) the parts that are not useful when one wants to eliminate
ambiguities by renaming.
Clarify a heading.
doc/user_guide.texi:
Document the above changes.
runtime/mercury_proc_id.h:
Fix a field name that has become misleading.
MR_UserProcId_Structs have a field named MR_user_arity.
In this name, the "MR_user_" part is a prefix shared by the other
fields in that structure, to indicate that they are part of the id
of a user-defined procedure, as opposed to a compiler-created
unify, compare or index procedure. However, the arity it contains
is what the compiler now calls a pred_form_arity: it does not count
type_info and typeclass_info arguments added by polymorphism, but
it *does* count function return values for functions. This is now
misleading, because in the compiler, a user_arity does *not* count
function return values for functions.
Replace this field name with MR_user_pred_form_arity, which tells
readers that this arity is a pred_form_arity. The presence of the
"user" part of the name may still cause some confusion, but at least
that confusion should motivate readers to look up the field name,
whose comment should clarify things.
mdbcomp/rtti_access.m:
runtime/mercury_debug.c:
runtime/mercury_deep_profiling.c:
runtime/mercury_ho_call.c:
runtime/mercury_layout_util.c:
runtime/mercury_ml_expand_body.h:
runtime/mercury_stack_layout.h:
runtime/mercury_trace_base.c:
trace/mercury_trace.c:
trace/mercury_trace_external.c:
trace/mercury_trace_util.c:
Conform to the change in mercury_proc_id.h.
tests/debugger/ambiguity.{m,inp,exp}:
tests/debugger/ambiguity_helper.m:
Expand this test case to test the new functionality.
The type specialized predicates are in a new helper module,
because this is the simplest way to avoid dead procedure elimination
deleting any of the predicates whose names we want to test for ambiguities.
compiler/options.m:
doc/user_guide.texi:
Introduce a new option, --debug-higher-order-specialization.
compiler/higher_order.m:
Print messages about procedures being specialized to a specific
higher-order value only if this new option is specified, not when
-V is specified, since these messages are of interest only to people
who are actively working on higher_order.m.
Check whether the option is enabled just once, rather than performing
that test, and possibly the creation of the progress output stream,
once per specialization.
compiler/dead_proc_elim.m:
If the new option --debug-dead-proc-elim is enabled, print information
about why each procedure (actually any entity) we cannot delete
is actually needed. This is the information we need when we want
to find out why procedures that we think should have been deleted
haven't been. This requires modifying the needed map to keep track
of this information.
Also, use the same option, instead of -V, to control whether we print
messages about which predicates/procedures have been eliminated,
since such messages are rarely of interest to anyone who is not actively
working on dead_proc_elim.m.
To allow these two sets of diagnostics to come out in the natural order
(first what we need and why, and then what we could eliminate), don't
print messages about what we eliminated as we go along. Instead,
gather up a map of what we eliminated from each affected predicate,
and print all the messages, in sorted order, at the end. Fix the
messages themselves by avoiding phrasing such as "Eliminated the dead
procedure function ...".
Refer to procedures in entities using a pred_proc_id instead of
separate pred- and proc_ids, to minimize the conversions required
to the new data structures.
Improve documentation.
compiler/options.m:
doc/user_guide.texi:
Add the new developer-only option --debug-dead-proc-elim.
compiler/mercury_compile_middle_passes.m:
Print the needed map and list of eliminated procedures only if
the new option is enabled.
compiler/deep_profiling.m:
compiler/inlining.m:
Conform to the changes in dead_proc_elim.m.
library/set_ctree234.m:
Enable a sanity check only with the right trace flag.
Mmakefile:
Ensure that the mercury_{compile,profile} executables exist
*before* attempting to build the manual pages.
doc/Mmakefile:
Rebuild the mprof.1 manual page if the profiler options.m
file changes.
compiler/add_clause.m:
Generate a warning for mode-specific clauses when the clause is for
a predicate that has only one mode, provided that the warning is enabled.
compiler/options.m:
Add an option to enable this warning.
doc/user_guide.texi:
Document this option.
library/exception.m:
library/int.m:
library/rtti_implementation.m:
library/string.m:
Delete modes from clause heads that would get this warning.
tests/valid/spurious_purity_warning.m:
Delete modes from clause heads that would get this warning.
Do not interleave predicate definitions.
tests/warnings/unneeded_mode_specific_clause.{m,exp}:
A test case for this warning.
tests/warnings/Mmakefile:
Enable the new test case.
tests/invalid/multimode_syntax.err_exp:
Expect the new warning.
Trail segments have been the default in trailing grades since Mercury 20.06.
Delete the trseg grade components and --trail-segment option since apart from
acting as synonyms for the tr component and --use-trail option repsectively,
they no longer do anything.
compiler/compute_grade.m:
compiler/handle_options.m:
compiler/options.m:
doc/user_guide.texi:
grade_lib/grade_vars.m:
scripts/parse_grade_option.sh-subr:
grade_lib/grade_string.m:
grade_lib/grade_vars.m:
Delete the trseg grade component and --trail-segments option.
compiler/add_pragma.m:
Update the wording of an error message.
NEWS:
Announce the above.
extras/trail/Mercury.options:
extras/trailed_update/Mmakefile:
extras/references/Mercury.options:
tests/invalid/test_feature_set.err_exp:
Conform to the above changes
doc/reference_manual.texi:
Give a reason why nonabstract instance declarations may not appear
in interface sections. To make this reason understandable, delay it
until we have discussed method definitions.
Add an example of an abstract instance declaration with a typeclass
constraint.
compiler/split_parse_tree_src.m:
Improve the wording along lines suggested by Julien.
tests/invalid_nodepend/instance_bug.err_exp:
Expect the updated wording.
doc/reference_manual.texi:
As above. The compiler enforced this requirement since April 2005,
but the manual was silent on the matter.
compiler/split_parse_tree_src.m:
When we detect an abstract instance declaration in the interface section,
extend the error message with a verbose-only mention of the usual fix.
tests/invalid_nodepend/Mercury.options:
Turn on verbose errors for this test case, which tests this error message.
tests/invalid_nodepend/instance_bug.err_exp:
Expect the new verbose component.
compiler/mercury_compile_main.m:
Implement the new option. Doing so without duplicating the existing
code tree of detect_libgrades required factoring out its reusable parts.
Do not pass I/O states to computations that do not need them.
Add XXXs for some questionable past decisions.
compiler/op_mode.m:
Define the new op_mode selected by the new option.
compiler/options.m:
doc/user_guide.texi:
Add and document the new option, and revert my screw-up of the
documentation of --output-libgrades.
compiler/options_file.m:
Make the interface of another predicate less error prone.
NEWS:
Mention the new option.
NEWS:
doc/reference_manual.texi:
Document the fact that the compiler now does such checks.
compiler/post_typecheck.m:
When propagating types into insts, ask inst_mode_type_prop.m to check
whether the types being propagated into user defined insts violate the
"for type_ctor" annotations on those insts.
Fix a bug in my earlier change. We want to propagate types into insts,
and check for applications of insts to values of inappropriate types
for lambda expressions. We used try to do it by traversing each procedure's
body goal, but this did nothing, because we copy goals to procedure bodies
in a pass that happens *after* the post-typecheck pass. During the
post-typecheck pass, these lambda expressions exist only in the predicate's
clauses, so that is where now we process them.
compiler/inst_mode_type_prop.m:
The code in this module is called not just from post_typecheck.m,
which needs this new check, but also from other modules, which do not.
To avoid excessive performance impact on the latter, make the
checking optional through a typeclass with two instances,
one of which prepares for and then does the checking, while the other
replaces all those operations with no-ops. Then use type_spec pragmas
to create two versions of all the predicates using this type class,
effectively creating two versions, one with the checks and the other
without the checks.
Change the name of all the exported predicates of this module
to specify whether they do these checks or not.
compiler/inst_lookup.m:
Conform to the changes above.
Note a possible performance problem.
compiler/add_special_pred.m:
compiler/inst_user.m:
Conform to the changes above.
tests/invalid/bad_type_for_inst.{m,err_exp}:
A test case for the error messages.
tests/invalid/Mmakefile:
Enable the new test case.
