compiler/options.m:
doc/user_guide.texi:
Add a new developer-only option, --std-int-file-not-written-msgs,
which, if specified, calls for the "file not written" messages
we generate when we want to write interface files but can't
to be written out in a standard form that deletes the directory
path component from the names of the files not written out.
In the long term, it is less work to add this option once
than to add a separate .err_exp file for each affected test case.
compiler/write_module_interface_files.m:
Obey the new option.
tests/invalid/ee_invalid.m:
Add C# and Java foreign_types next to the C foreign_type.
tests/invalid/erroneous_throw_promise.m:
Add C# foreign_procs next to the C and Java foreign_procs.
tests/invalid/exist_foreign_error.m:
Add C# and Java foreign_procs next to a C foreign_proc.
tests/invalid/exist_foreign_error.err_exp:
tests/invalid/exist_foreign_error.err_exp2:
tests/invalid/exist_foreign_error.err_exp3:
Update the line number in the expected error output file for C,
and add expected error output files for Java and C#.
tests/invalid_make_int/bug17.{m,int_err_exp}:
tests/invalid_make_int/builtin_int.{m,int_err_exp}:
Move these test cases here from tests/invalid, since all the errors
we test for are reported when making the .int file.
tests/invalid/Mmakefile:
Delete the tests moved to tests/invalid_make_int.
tests/invalid_make_int/Mercury.options:
tests/invalid_make_int/Mmakefile:
Add the tests moved from tests/invalid. Specify the new option
for all the test cases.
Several places in the runtime make use of the program basename. This is
computed by stripping any directory qualification from the value of argv[0].
Currently, this is done by searching for uses of '/' as a directory separator.
This does not work on Windows where '\' is the directory separator and paths
may also be drive qualified. This diff adds a function that will handle
Windows-style paths.
Also, none of the uses of the program basename in the runtime currently account
for the presence of the .exe executable extension on Windows. After this diff,
users won't have to, and in fact will not be allowed to, include the .exe
extension in the program name in these contexts.
runtime/mercury_runtime_util.[ch]:
Add a function, MR_get_program_basename(), whose job is
to strip any drive or directory qualification, and the executable
extension from a given path. On Windows, we use the OS's splitpath()
function to do this.
Add an XXX about the .exe extension on Cygwin.
runtime/mercury_wrapper.c:
Use the new function when computing:
- the name of the program-specific MERCURY_OPTIONS environment variable;
- the value of the --trace-count-if-exec runtime option;
- the value of the --coverage-test-if-exec runtime option.
doc/user_guide.texi:
Document that the .exe extension is not expected in the three spots above.
slice/mdice.m:
slice/mslice.m:
Add the suffix "_width", to the names of the option used to control column
widths in the output.
Adjust the usage message.
docs/user_guide.texi:
Conform to the above change.
compiler/handle_options.m:
Do not prefix the copyright section of the usage message
with "Copyright:" since this causes the make_manpage script
to include a second COPYRIGHT section.
doc/make_manpage:
Skip over lines beginning with "Copyright" since the script
generates a standard copyright notice at the end of each
manual page.
doc/user_guide.texi:
Change the documentation of this option to clariy that we evaluate
at compile-time only calls to a subset of library predicates/functions.
compiler/options.m:
Add the updated documentation in user_guide.texi as the comment
explaining this option, which was not documented here before.
doc/user_guide.texi:
Document that the letter Y in dump_options requests that insts
be dumped in a way that uses indentation to express structure.
compiler/handle_options.m:
Specify Y by default in the dump aliases which also set D
(which causes insts to be printed).
Put all upper case letters together.
compiler/hlds_out_goal.m:
If Y is set, then use error_msg_inst.m's facilities to dump insts
in instmap_deltas in a structured fashion.
compiler/hlds_out_inst_table.m:
If Y is set, then use error_msg_inst.m's facilities to dump insts
in the various inst tables.
Rejig the set of places at which we print newlines to make the output
look right both with and without Y.
compiler/hlds_out_module.m:
compiler/options.m:
doc/user_guide.texi:
As above. --no-output-compiler-error-lines specifies that all the lines
of the .err file should be written out.
compiler/make.build.m:
Update the code copying the first N lines of a .err file to the current
output stream to handle the newly-possible absence of a limit, as well
as the existing situation where there is a limit.
compiler/make.module_dep_file.m:
Print all of a file, not just 10000 lines, in the presence of a fatal
error.
doc/reference_manual.texi:
Rewrite the manual section on higher order insts.
This used to be in subsection 9.3.1 "Builtin higher-order insts and modes",
but from a user's perspective, the insts and modes they want to use
and need education about are NOT themselves builtin. (The forms they
may take are builtin, but that is true for every part of the syntax
of Mercury.) Therefore this diff deletes the old section header for 9.3.1,
making the updated text part of 9.3 itself.
Make the new text show examples before showing the general case.
Move the paragraphs about the prohibition on unifying/comparing
higher order terms to its own section; it did not fit into the
section on higher order insts and modes.
Fix some old spelling errors.
Given a switch arm that matches several cons_ids, and which contains
one or more switches on the *same* variable, such as the arm for
f1/f2/f3/f4 below,
(
(X = f1 ; X = f2 ; X = f3 ; X = f4),
...
(
X = f1,
...
;
(X = f2 ; X = f3),
...
;
X = f4,
...
),
...
;
...
)
this new optimization
- partitions the set of cons_id in that arm (in this case, {f1,f2,f3,f4})
as finely as needed by any other the switches on X in that arm
(in this case, that is three partitions containing {f1}, {f2,f3} and {f4}),
- splits that original switch arm into N arms, one arm for each partition,
making a copy of the switch arm's goal for each partition,
- restricts any switches on the original switch variable (in this case, X)
inside the copy of the arm goal inside each new case to only the cons_ids
in that case's partition, and then replacing any resulting one-arm switches
with the just goal inside that one arm.
The code resulting from these three steps will include some code duplication
(some of the pieces of code denoted by ... in the example above would be
duplicated), but it will need to execute fewer transfers of control.
This is worthwhile because (a) the branch instructions used to implement
switches are hard to predict unless most paths through the nested switches
are rarely if ever taken, and (b) the pipeline breaks caused by branches
that are not correctly predicted are one of the two major contributors
to the runtime of Mercury programs. (The other major contributors are
data cache misses.)
The implementation of this option has two major parts.
- Part 1 consists of discovering whether a procedure body contains
any code in which a switch on a variable is nested inside an arm
of another switch on that same variable. For any instance of such
a pair of switches, it records the identity of the variable and
the set of cons_ids of the outermost arm.
- Part 2 consists of actually transforming the procedure body
by splitting each outermost switch arm thus recorded. (This part
contains all three of the steps above.)
We integrate part 1 with the usual procedure body traversal of the
simplification pass, which makes it quite cheap. In most procedure bodies,
it won't find any nested switches meeting its criteria. We execute part 2,
which is relatively expensive, only if it does.
compiler/simplify_info.m:
Add a new type, switch_arm, which represents one arm of a switch.
Add a new field to the simplify_nested_context type. Its type
is list(switch_arm), and it represents the stack of switch arms (if any)
that the goal currently being simplified is inside. simplify_goal_switch.m
uses this field to detect switches that occur inside an arm of an
ancestor goal that is also a switch on the same variable.
Add a new field to the simplify_info, a set of switch_arms,
that denotes the set of switch arms from which that detection
has actually happened, and which should therefore be
partitioned and split.
compiler/simplify_goal_switch.m:
Add the code for doing the detection and recording mentioned just above.
This is the Part 1 mentioned above.
compiler/split_switch_arms.m:
This new module implements the splitting up process.
This is the Part 2 mentioned above.
compiler/simplify.m:
Include the new module in the simplify subpackage of the check_hlds
package.
compiler/notes/compiler_design.html:
Document the new module.
compiler/simplify_proc.m:
Invoke split_switch_arms.m (part 2) if the part of simplify_goal_switch.m
implementing part 1 has found any work for it to do.
compiler/simplify_tasks.m:
Add split_switch_arms as one of the tasks that simplification
may be asked to do. Set its default value from the value of
a new optimization option that, when specified, calls for it to be done.
compiler/options.m:
Add this option, --split-switch-arms.
Change the internal name of an existing option,
everything_in_one_c_function, to the one expected by
tools/make_optimization_options_middle.
Replace the part of this file that is constructed by
tools/make_optimization_options_middle.
doc/user_guide.texi:
Document the new option.
tools/make_optimization_options_db:
Add --split-switch-arms to the optimization tuple.
Fix software rot by
- renaming optimize_tailcalls to optimize_mlds_tailcalls inside the
optimization tuple, as it has been in options.m, and
- deleting erlang_switch_on_strings_as_atoms from the opt_tuple,
as it has been from options.m.
tools/make_optimization_options_end:
Enable the new option by default at optimization level 2.
tools/make_optimization_options_middle:
Fix bugs in this script, which generates compiler/optimization_options.m.
One bug was that it referred to the opt_level and opt_space options
by the wrong name (optopt_level and optopt_space respectively).
The other bug was that it expected opt_level to be a string_special option,
when it is an int_special option.
Make the handler_file this script generates easier to put into options.m
by not generating a line that (a) already exists in options.m, and
(b) would need to have a comma put after it, if one wanted this line
to replace the copy already in options.m.
compiler/optimization_options.m:
Rebuild this file after the changes above.
compiler/simplify_goal_unify.m:
Conform to the changes above.
compiler/inst_merge.m:
Mark two predicates, inst_merge_[34], to be inlined. The intention
is that inst_merge_4 should be inlined into inst_merge_3, and then
inst_merge_3 should be inlined inside inst_merge_2; that would then
generate six levels of switches, three on one of the insts to be
merged and three on the other, which the new optimization could
then flatten. Unfortunately, inlining does not do this yet.
tests/hard_coded/test_split_switch_arms.{m,exp}:
A new test case for the the new transformation.
tests/hard_coded/Mmakefile:
tests/hard_coded/Mercury.options:
Enable the new test case, and specify the new option for it.
compiler/file_names.m:
Delete now-obsolete comments. Move their still-relevant parts
next to the entity that they apply to.
List the string form, if any, of each enum representing an extension.
Explain the meaning of _gs, _ngs and _opt suffixes.
Delete obsolete commented-out code.
Delete an obsolete, unused type definition.
compiler/options.m:
doc/user_guide.texi:
Fix two bugs that a comment that this diff pointed to.
First, since 2017, the --dump-hlds option has output C code
only if the target language is C, but the documentation
of that option did not mention this. Fix this omission.
Second, ever since we split .mh and .mih files, the header
part of MLDS dumps in C form were output to .mih_dump file.
However, the documentation of the --dump-hlds option said that
it was output to a .h_dump file. Fix this as well.
library/term_io.m:
Put related predicates next to each other. Put the groups of related
predicates into descending order on the size of the entity being output.
We have two groups of predicates that both output atoms, with one group
taking an adjacent_to_graphic_token argument, and one group not taking
such an argument. The second group is publicly exported; the first group
is exported but not publicly documented.
Until now, we arranged the "exported but not publicly documented" part
by declaring these predicates in a second interface section. However,
this is incompatible with them being next to second group. Switch
to using the new mechanism in doc/Mmakefile to achieve the same
objective.
doc/Mmakefile:
Do not include any lines between lines containing the strings
UNDOC_PART_START and UNDOC_PART_END in library/*.m in the library's
documentation.
library/mercury_term_lexer.m:
As above.
NEWS.md:
Announce the change.
doc/reference_manual.texi:
Document the change.
tests/hard_coded/parse_number_from_string.exp:
tests/invalid_nodepend/invalid_float_literal.err_exp:
Update these expected outputs after the change.
compiler/options.m:
Delete the option.
doc/user_guide.texi:
Delete its documentation.
NEWS.md:
Announce the deletion.
compiler/file_names.m:
compiler/make.program_target.m:
Delete references to the option.
--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.
