compiler/options.m:
Move --warn-simple-code to the "warnings about dodgy code"
category, as
- most of the issues that it warns about are indeed evidence
of dodgy code, and
- its existing documentation also states that it is intended
to report likely-to-be-incorrect code.
Change the internal name of --warn-simple-code, in order to force
all its existing uses to be reclassified.
Let the --warn-redundant-code part stay in the style issues category,
since the code will work just the same if the redundancies are removed.
NEWS.md:
Announce the new option.
compiler/simplify_goal_call.m:
Reclassify all uses of --warn-simple-code.
Add a missing condition in an if-then-else.
compiler/add_clause.m:
compiler/add_type.m:
compiler/check_type_inst_mode_defns.m:
compiler/convert_import_use.m:
compiler/convert_parse_tree.m:
compiler/det_analysis.m:
compiler/det_infer_goal.m:
compiler/mercury_compile_front_end.m:
compiler/mode_errors.m:
compiler/simplify_goal.m:
compiler/simplify_goal_disj.m:
compiler/simplify_goal_ite.m:
compiler/simplify_info.m:
compiler/simplify_tasks.m:
compiler/state_var.m:
Reclassify all uses of --warn-simple-code.
tests/warnings/help_text.err_exp:
Expect the updated help text.
compiler/options.m:
Rename the internal names of these three options. Keep the old
external names, but make the main external name the new name.
NEWS.mdb:
Announce the renames.
compiler/check_options.m:
compiler/det_check_proc.m:
compiler/det_check_switch.m:
compiler/simplify_goal_ite.m:
Conform to the change above. Change the severity of the messages
controlled by the changed options severity_warning.
tests/warnings/help_text.err_exp:
Expect the updated help text.
The objective of this step is two-fold:
- to fix --inhibit-warnings, making it shut up all warning
and informational messages; and
- to ensure that it *stays* fixed, even when after new diagnostics
are added.
As part of this fix, this diff adds a whole bunch of new warning
options, in order to control the warnings that previously were
not controlled by any option. (There was no need for new
informational options.)
As it happens, we have long used severity_informational for messages
that did not report any information about the code being compiled,
but to report actions that the compiler was taking. Create a new
option category, oc_report, for the new options that now control
those diagnostics.
---------------------
compiler/error_spec.m:
Change severity_warning and severity_informational to take an option
as as argument. The semantics is that the diagnostic in which
the severity occurs is conditional on that option, meaning that
it is printed only if that option is set to "yes".
Delete the severity_conditional function symbol from the severity
type, since the mechanism just above handles its only use case.
Define subtypes to represent error_specs in a standard form.
compiler/error_sort.m:
Provide operations to convert error specs into their standard form.
Make the sorting operation itself operate on the standard form.
compiler/write_error_spec.m:
Convert error_specs to standard form before writing them out,
in order to avoid duplicating the code for their standardization.
Change the code that writes out error_specs to operate on the
standard form. Implement the test implicit in the warning and
and informational severities in this code.
compiler/error_util.m:
compiler/compiler_util.m:
Delete operations that do not make sense with the new severity type.
---------------------
compiler/options.m:
Add new options to control all the previously-uncontrolled
warning and informational messages.
NEWS.md:
Announce the *public* new options.
compiler/option_categories.m:
compiler/print_help.m:
Add the new option category, and fake-include it in the help text
and the user guide. (The inclusion is fake because none of the
options in the new category are user visible, meaning the section
containing them is not visible either.)
---------------------
compiler/det_infer_goal.m:
Start a severity warning diagnostic with "Warning:"
instead of "Error:".
compiler/mark_trace_goals.m:
Fix an incorrect error message.
compiler/purity.m:
Replace a correct/incorrect color pair with two inconsistent colors,
because there is a reasonable probability of each one being right.
---------------------
compiler/accumulator.m:
compiler/add_clause.m:
compiler/add_mode.m:
compiler/add_pragma.m:
compiler/add_pragma_tabling.m:
compiler/add_pred.m:
compiler/add_type.m:
compiler/check_module_interface.m:
compiler/check_type_inst_mode_defns.m:
compiler/check_typeclass.m:
compiler/color_schemes.m:
compiler/common.m:
compiler/convert_import_use.m:
compiler/convert_parse_tree.m:
compiler/dead_proc_elim.m:
compiler/det_check_proc.m:
compiler/det_check_switch.m:
compiler/det_infer_goal.m:
compiler/du_type_layout.m:
compiler/format_call_errors.m:
compiler/grab_modules.m:
compiler/hlds_call_tree.m:
compiler/inst_check.m:
compiler/introduce_parallelism.m:
compiler/make_hlds_error.m:
compiler/make_hlds_warn.m:
compiler/mark_tail_calls.m:
compiler/mark_trace_goals.m:
compiler/mercury_compile_main.m:
compiler/mercury_compile_make_hlds.m:
compiler/mode_errors.m:
compiler/modes.m:
compiler/module_qual.qual_errors.m:
compiler/opt_deps_spec.m:
compiler/options_file.m:
compiler/parse_goal.m:
compiler/post_term_analysis.m:
compiler/post_typecheck.m:
compiler/pre_typecheck.m:
compiler/purity.m:
compiler/read_modules.m:
compiler/recompilation.check.m:
compiler/simplify_goal.m:
compiler/simplify_goal_call.m:
compiler/simplify_goal_disj.m:
compiler/simplify_goal_ite.m:
compiler/split_parse_tree_src.m:
compiler/state_var.m:
compiler/stratify.m:
compiler/style_checks.m:
compiler/superhomogeneous.m:
compiler/table_gen.m:
compiler/term_constr_errors.m:
compiler/term_errors.m:
compiler/termination.m:
compiler/typecheck_clauses.m:
compiler/typecheck_error_overload.m:
compiler/typecheck_error_undef.m:
compiler/typecheck_errors.m:
compiler/typecheck_msgs.m:
compiler/unused_args.m:
compiler/unused_imports.m:
compiler/warn_unread_modules.m:
compiler/write_module_interface_files.m:
Conform to the changes above, mostly by either
- adding an option to all warning and informational messages,
sometimes using existing warning options and sometimes new ones,
or
- turning already explicitly-conditional-on-an-option messages
into implicitly-conditional-on-that-option messages.
---------------------
tests/invalid/one_member.m:
Conform to the change in det_infer_goal.m.
tests/invalid/require_tailrec_1.err_exp:
tests/invalid/require_tailrec_2.err_exp:
Actually obey the options for these modules in Mercury.options.
tests/invalid_purity/purity.err_exp:
tests/warnings/purity_warnings.err_exp:
Conform to the change in purity.m.
tests/warnings/moved_trace_goal.err_exp:
Conform to the change in mark_trace_goals.m.
tests/warnings/help_text.err_exp:
Expect the documentation of all the new options.
There are currently two separate predicates used for invoking the C# compiler.
One is in link_target_code and is used to create executables and libraries
in the C# grade. The other is compile_target_code and was previously used
by the old .NET backend to compile additional C# source files. It is currently
plugged into the code that compiles the source files used for fact tables, but
as they are not supported by the C# backed, it has never been used in practice
for this purpose.
Delete the code for invoking the C# compiler in compile_target_code, since it
will have no users after this diff and is almost certainly affected by bitrot
at this point.
compiler/compile_target_code.m:
Delete the compile_csharp_file/8 predicate. It is unused.
compiler/make.module_target.m:
Abort if we are requested to build a Java or C# foreign code file.
The only thing that currently makes such requests is compilation of
fact tables and neither the Java or C# backend supports those.
Add an explanation of an issue in an XXX.
compiler/link_target_code.m:
Add an XXX about the MS C# compiler that needs to be investigated.
On my laptop, this yields a speed of of probably around 0.7 to 0.8 percent,
though thermal throttling makes it difficult to be sure.
compiler/make_module_file_names.m:
Change the cache from being
ext->module_name->file_name_string
to
module_name->{module_name_string, ext->file_name_string}.
This allows us to pay the cost of the intermediate allocations
needed to construct module_name_strings just once for each module_name.
Delete the old comment about an old version of approach not being viable,
because, with the addition of the module_name->module_name_string cache,
it *is* viable.
Don't include duplicate info in the printed cache performance report.
When we want to construct many filenames with the same extension,
do the extension-related parts of the work just once.
compiler/file_names.m:
Export the operations needed to make the new code in
make_module_file_names.m possible.
The change to d_file_deps.m two days ago fixed a correctness problem,
but it increased the runtime of "mmc --generate-dependencies mercury_compile.m"
from about 5 seconds on laptop to about 85 seconds. This diff reduces the
runtime to about 7 seconds, reducing the performance cost of the correctness
fix from about 15x to about 1.4x.
compiler/d_file_deps.m:
Instead of computing reachability separately in five digraphs
and unioning the results (which must be done separately for each
module we are generating a .d file for). union the digraphs themselves,
which can be done just once.
Compute reachability using an algorithm designed for just this purpose,
not dfs, which spends extra resources on returning the reachable
vertices in a particular order.
library/digraph.m:
Add the specialized reachability-only predicate.
NEWS.md:
Announce the new predicate in digraph.m.
scripts/mtags.in:
If we are considering generating a duplicate tag, do not generate it
if the new location and the old are within five lines of each other.
To make this change possible, simplify the logic that deals with
duplicate tags.
Mmake.common.in:
Before this diff, there were a whole bunch of definitions between
the inclusion of Mmake.workspace and the inclusion of Mmake.params.
Move all those definitions elsewhere. Specifically, move the definitions
whose right hand sides are autoconfigured values, and which are NOT
also set by Mmake.workspace, to before both inclusions, moving related
non-autoconfigure variable definitions with them, while moving
other definitions to after both inclusions.
Document the cause of the "phasing problem" that kept the inclusion
of Mmake.params after the inclusion of Mmake.workspace (the definition
of MC), and a possible solution.
tools/stdlines_for_sh:
Add a version of stdlines for sh scripts.
Before this diff,
- the .d filed generated by "mmc --generate-dependencies mer_std.m", and
- the .d files generated by compiling all the modules in the library
had *two*-way differences: the first set of .d files contained dependencies
that the second did not, and *vice versa*. The latter differences were bugs.
Now, as far as I can tell from the deluge of data,
"mmc --generate-dependencies" generates a superset of the dependencies
generated by code generating compiler invocations, which is a safe
overapproximation of the actual dependencies.
compiler/generate_mmakefile_fragments.m:
Flatten the d_file_deps structure by effectively inlining the std_deps
structure inside it, and putting the resulting fields into a meaningful
order. Document the resulting structure as well as I can.
Use notag types to record the intended semantics of some fields
into their values, with the intention of making them harder to misuse.
They were misused before this diff; in particular, a missing module
name in one of these fields would reliably lead to the failure
of the hard_coded/foreign_import_module test case in hlc grades,
though only with a sequential invocation of mmake. (The bug was
that after "mmc --generate-dependencies foreign_import_module.m",
foreign_import_module.d was missing the dependency of
foreign_import_module.o on foreign_import_module_helper_1.mh,
and therefore the compilation foreign_import_module.c got a gcc abort
complaining about this .mh file being missing. The reason for
the bug being intermittent was that the mmc invocation that created
foreign_import_module.c would add the missing dependency, so *later*
mmake invocations, though not existing ones, would know
to build that .mh file.)
Generate rules for object files depending on .mh files that
account for both foreign_import_module declarations, and for
foreign type definitions. Add an XXX about the absence of the
information we need to properly handle the latter in the presence
of intermodule optimization.
Generate just one rule for object files depending on .mh files,
instead of generating two (one for the dependencies that exist
without intermodule optimization, and for one those that exist only
with intermodule optimization.)
Flatten the intermod_deps structure as well. It used to have two
components that encoded the outcomes of two *almost* identical tests,
but a change to d_file_deps.m below makes them actually identical,
so they do not need to be recorded twice.
Inline the old (and misnamed) gather_foreign_import_deps predicate
at its only call site, for greater clarity.
Simplify the code constructing some actions.
Use more specifically descriptive predicate and variable names.
compiler/d_file_deps.m:
Stop requiring the caller of construct_d_file_deps_gendep to pass
an aug_compilation_unit; get it to pass instead two of its components,
the only ones that are meaningful and also the only ones we actually need:
the parse_tree of the module in question and its baggage.
Eliminate some unnecessary differences between compute_d_file_deps_gendep
and compute_d_file_deps_hlds by replacing some existing tests for just
--intermod-opt with tests for *either* --intermod-opt *or* --use-opt-files,
which is the test used elsewhere for the same purpose in the rest of this
module. The two tests are equivalent for now, because handle_options.m
force-sets --no-use-opt-files. And even when we undo that force-set,
the new test will actually be what we want.
Completely redo the code that computes the dependencies that
generate_mmakefile_fragments.m converts into the dependencies
of object files on .mh files.
Give some predicates more meaningful names.
compiler/mmakefiles.m:
Add a mechanism to allow the simplification of some codes
creating actions.
compiler/module_deps_graph.m:
Give a type a more descriptive name.
Document a predicate.
Add an XXX.
compiler/make.program_target.m:
compiler/write_deps_file.m:
Conform to the changes above.
compiler/intermod.m:
Fix comment rot.
compiler/parse_tree_out_item.m:
Generate more readable output for foreign_enum pragmas.
library/digraph.m:
Put the predicates/functions of this file into meaningful groups.
We have several operations that have two names, one old and short,
and one newer, longer and more descriptive. Implement the short named
versions in terms of the longer named versions, not vice versa.
Give some internal predicates more meaningful names.
There are no algorithmic changes in this module.
browser/Mmakefile:
Update a comment.
scripts/mmake.in:
Allow $MMAKE_DEBUG to specify what debug flags to invoke gmake with.
Previously, we used to build e.g. mercury_ref.info from reference_manual.texi.
We now use these base files names consistently, with all relevant extensions:
mercury_reference_manual
mercury_user_guide
mercury_library_manual
mercury_transition_guide
mercury_faq
doc/mercury_reference_manual.texi:
doc/mercury_user_guide.texi:
doc/mercury_library_manual.texi:
doc/mercury_transition_guide.texi:
doc/mercury_faq.texi:
Rename the original .texi files to the new names.
Rename any pointers between manuals.
doc/update_opts:
Delete this unused file, since there is no point in updating it
to use the new file names.
doc/Mmakefile:
Rename files in variable definitions, target lists, source lists, actions,
and comments.
Replace blocks of file-name-specific rules with a single generic rule
where the uniformity of names makes this possible.
Start builtin pdf files by default, since the motivation for this change
is fixing an inconsistency between .html and .pdf versions of the same
manual.
Change the naming scheme of intermediate files to fit into the new pattern.
Delete the new_opts target, which we do not need anymore.
Delete references to library_toc and library_1, which we stopped building
in 2003.
doc/mercury.html.in:
doc/mercury.info.in:
Conform to the renames.
compiler/lp_rational.m:
compiler/polyhedron.m:
Rename a function in each module.
compiler/term_constr_fixpoint.m:
compiler/term_constr_pass2.m:
Conform to the renames.
runtime/mercury_grade.h:
Rename the grade modifier, and the C macro that represents it.
compiler/options.m:
Rename the --c-debug-grade option to --target-debug-grade.
compiler/compute_grade.m:
Rename the grade modifier, and the option that represents it.
Restrict the .target_debut grade modifier to MLDS grades.
compiler/handle_options.m:
Implement --target-debug-grade by having it imply --target-debug.
compiler/compile_target_code.m:
compiler/link_target_code.m:
Pay attention to either --target-debug-grade (for purposes related
to the grade itself) and to --target-debug (for all other purposes).
scripts/canonical_grade.in:
scripts/canonical_grade.sh-subr:
scripts/final_grade_options.sh-subr:
scripts/init_grade_options.sh-subr:
scripts/parse_grade_options.sh-subr:
Parse target_debug grade modifiers and --target-debug-grade options
instead of c_debug grade modifiers and --c-debug-grade options.
Add (normally commented-out) infrastructure to make it easier
to debug changes.
Restrict the .target_debut grade modifier to MLDS grades.
scripts/mgnuc.in:
scripts/mgnuc_file_opts.sh-subr:
Rename some variables to clarify the distinction between the
--target-debug option (which, like -g, enabled debugging of only one file)
and the --target-debug-grade option (which enables it for the whole
program).
configure.ac:
Make it easier to debug grade-related changes by recording
both autoconfigured and user-supplied grades that the rejected by
the canonical_grade script.
Conform to the changes above.
README.sanitizers:
doc/user_guide.texi:
grade_lib/grade_spec.m:
grade_lib/grade_string.m:
scripts/ml.in:
tests/warnings/help_text.err_exp:
tools/lmc.in:
tools/test_mercury:
Conform to the changes above.
scripts/Mmake.vars.in:
Add some XXXs about style.
Despite using --use-mmc-make when we build Mercury in the C# or Java grades, we
still need to run the depend target in order ensure that its various other
actions take place (e.g. copying files from the mdbcomp directory to the slice
directory). Not explicitly invoking the depend target, can result in timing
related problems, especially when using parallel builds. Modify the
documentation for building C#/Java compilers to include an explicit depend
step.
README.CSharp.md:
README.Java.md:
As above.
