mirror of
https://github.com/Mercury-Language/mercury.git
synced 2026-04-15 17:33:38 +00:00
We have never supported abstract insts, and we are not likely to start
using them any time soon, but we have had them in the representation of insts
since the beginning. Since they were never actually generated, the code
that operated on them was never really tested, which is good, because
in many places, that code simply threw an exception. The code that didn't
throw an exception when it found an abstract inst had to work correctly
for the abstract_insts that we actually generated, which were abstract
only in the sense that they were references to a would-be user-defined inst
name that wasn't actually defined.
There were two sources of such "abstract" insts.
- One was failed calls to inst_lookup that specified an user_inst inst_name.
- The other consisted of predicates whose job was to construct error messages
involving insts. These either converted cons_ids into abstract insts,
or mangled valid user_inst inst_names into invalid user_inst inst_names,
because error_msg_inst.m generated good-looking messages when given
the results of such conversions.
The first is handled by the fact that module qualification detects and
reports references to undefined insts and modes, and does not let the
compiler proceed to the compiler phases that may call inst_lookup.
The second is handled by the changes to error_msg_inst.m below.
These change to handle the use cases of the two error-message-constructing
predicates that used to employ abstract_insts, but now employ user_inst
defined_insts with a two particular kinds of undefined inst ctor,
one for each use case.
compiler/prog_data.m:
Delete the abstract_int function symbol from the mer_inst type.
compiler/inst_lookup.m:
When the lookup of an user_inst inst_name inside a defined_inst
fails, don't convert that defined_inst into abstract inst,
throw an exception.
compiler/error_msg_inst.m:
Add code to deal with the insts that add_mutable_aux_preds.m and
mode_errors.m generate for us to convert to lists of error message pieces.
The addition is done twice, in an as identical a fashion as possible,
when generating non-inline pieces and when generating inline pieces.
compiler/add_mutable_aux_preds.m:
compiler/mode_errors.m:
Document how these modules cooperates with error_msg_inst.m.
compiler/add_mode.m:
compiler/comp_unit_interface.m:
compiler/direct_arg_in_out.m:
compiler/equiv_type_hlds.m:
compiler/float_regs.m:
compiler/hlds_code_util.m:
compiler/hlds_out_goal.m:
compiler/hlds_out_mode.m:
compiler/hlds_statistics.m:
compiler/inst_abstract_unify.m:
compiler/inst_check.m:
compiler/inst_match.m:
compiler/inst_merge.m:
compiler/inst_mode_type_prop.m:
compiler/inst_test.m:
compiler/inst_user.m:
compiler/inst_util.m:
compiler/make_hlds_passes.m:
compiler/mode_top_functor.m:
compiler/modecheck_coerce.m:
compiler/modecheck_util.m:
compiler/module_qual.qualify_items.m:
compiler/parse_tree_out_inst.m:
compiler/parse_tree_to_term.m:
compiler/pd_util.m:
compiler/prog_mode.m:
compiler/recompilation.usage.m:
compiler/types_into_modes.m:
compiler/unused_imports.m:
compiler/xml_documentation.m:
Conform to the changes above, mostly by deleting code dealing with
abstract_insts.
tests/invalid/functor_ho_inst_bad.err_exp:
tests/invalid/functor_ho_inst_bad_3.err_exp:
tests/invalid/partial_implied_mode.err_exp:
tests/invalid_nodepend/occurs.err_exp:
Update these expected outputs, which each involve errors generated
by the modified code in mode_errors.m or add_mutable_aux_preds.m.
Some of these referred to some things as "named insts" when they were
*not* named insts in the program.
tests/invalid_nodepend/kind.{m,err_exp}:
Add some invalid code to this test, and update the expected output
accordingly.
# vim: ts=4 sw=4 expandtab
The Mercury test suite is (dis)organized into a flat set of directories.
`mmake' will run the tests in the directory it is invoked in.
To run just the tests that failed in a previous test run, use
`mmake ERROR_FILE=FILE', where FILE is a copy of the runtests.errs file
from the previous run.
Both the bootcheck script and the nightly script use `mmake'
to run all the tests.
Unless otherwise stated, the tests in each directory compile
the test programs and compare their output against hand-coded
`.exp' (or `.exp2', `.exp3', etc) files.
NOTE: if you add a new (sub)directory to the test suite then you may
need to update the value of the variable `all_test_dirs' in tools/bootcheck.
analysis*
These directories are for testing the intermodule analysis framework.
The different directories test different analyses:
analysis_ctgc and analysis_sharing tests different aspects of
the analyses for compile-time garbage collection.
analysis_excp tests analysis for what code can throw what exceptions.
analysis_external tests that even procedures are external (i.e. procedures
that don't have Mercury code) have analysis results recorded for them
(presumably results that are safe approximation of *anything*).
analysis_table tests analyses for what code contains minimal model
tabling.
analysis_trail tests analyses for what code contains trailing
operations.
analysis_unused_args tests analyses for what arguments are unused
in each procedure.
analysis itself contains machinery shared between all these directories,
benchmarks
This directory contains Mercury versions of the benchmarks programs
from the initial Mercury paper in the Journal of Logic Programming.
debugger
declarative_debugger
These directories are for testing mdb, the Mercury debugger.
The second is for testing the declarative debugging features of mdb,
the first is for testing everything else.
The tests in these directories are performed only in LLDS grades,
since execution tracing is supported only in those grades.
dppd
This directory contains a Mercury version of the Prolog test suite
named "dozens of problems in partial deduction". As its name says,
it tests the effectiveness of the compiler's partial deduction
(also known as partial evaluation) capabilities.
exceptions
This directory contains tests of Mercury's handling of exceptions.
feedback
This directory contains tests of whether, given the deep profile
of a program and a representation of the program itself, our
autoparallelization system generates the expected recommendations
about what parts of the program are worth parallelizing,
as shown by the generated feedback report.
general
hard_coded
These directories are for general test cases.
The historical reason for the separate `general' and `hard_coded'
directories was that the tests in `general' worked with NU-Prolog
and compared the Mercury output with the NU-Prolog output, but
the tests in `hard_coded' didn't work with NU-Prolog, so their
expected output needed to be hard-coded. We no longer support
compilation with NU-Prolog, so everything goes in hard_coded now.
(It might be a good idea to split hard_code into (a) tests of
particular features and (b) regression tests that check for old bugs.
But for the moment, just about every test for whether a program
generates the expected output goes in hard_coded.)
grade_subdirs
This directory tests the correct handling of --use-grade-subdirs.
invalid*
These directories are for test cases that are invalid programs.
We check that the files do *not* compile, and check that the errors
match those in the hand-written `.err_exp' file.
invalid_onlydepend tests errors that occur when executing
"mmc --generate-dependencies".
invalid_nodepend contains tests which get errors executing
"mmc --generate-dependencies", but which test errors that occur
during normal compilation (i.e. when generating code, or with
--errorcheck-only).
invalid_make_int tests errors that occur when executing
"mmc --make-interface".
invalid_purity tests errors involving purity.
invalid_submodules tests errors involving nested submodules.
(Some involve separate submodules as well.)
invalid itself is for tests of all other kinds of errors.
misc_tests
This directory contains tests that don't fit anywhere else.
At the moment, it tests symbol name demangling and the
compiler's ability to "prettyprint" a Mercury module
(whose output goes into an appropriately named .ugly file).
mmc_make
As its name says, this directory contains tests of "mmc --make".
par_conj
This directory contains tests of parallel conjunctions in the LLDS
backend.
purity
This directory tests the correct behaviour of code that mixes
different levels of purity.
recompilation
This directory contains tests of the smart recompilation system.
As well as checking for the correct output from the test programs
these tests also examine the `.err' files to make sure that
all necessary recompilations are performed.
stm
This directory contains tests of the compiler's experimental
support for software transactional memory. Since that support was
never finished, bootcheck doesn't execute the tests in this directory.
string_format
This directory tests the correct operation of string.format and
related predicates.
structure_reuse
This directory tests whether code transformed (optimized)
by the structure_reuse package still generates the expected output.
submodules
This directory tests whether splitting up code between several
submodules, either nested or separate, affects its output.
tabling
This directory tests all forms of tabling: memoing, loop detection,
and minimal model.
term
This directory tests the compiler's termination analyser. These tests
work by comparing the contents of the .trans_opt file emitted by the
compiler with the hand-written `.trans_opt_exp' file. This directory
is also used for testing the compiler's exception analysis.
trailing
This directory contains tests that make use of the trail.
These tests are only run in trailing grades.
typeclasses
This directory tests the correctness of code that uses typeclasses.
valid*
These directories are for test cases that are not complete programs;
we just check whether they compile.
valid_make_int tests whether "mmc --make-interface" succeeds on modules.
valid_seq contains tests with nested submodules, which should be
compiled sequentially. (If the different nested submodules are
compiled in parallel, the interface files they want to read
may not have been created yet, leading to spurious errors).
valid contains all other validity tests.
warnings
This directory is for tests of compiler warnings. These work by
comparing the warnings emitted by the compiler with those given
in the hand-written `.exp' file.