9e01e8da4a
compiler/add_mutable_aux_preds.m:
compiler/hlds_code_util.m:
Move the code that tests the insts in mutables to see if they are allowed
in mutables from hlds_code_util.m to add_mutable_aux_preds.m, since that
code is not a generally useful utility.
Change that code so that instead of generating the same error message
("this is not a valid inst for a mutable") for all errors, we now
(a) generate a separate error message for each problem in the inst, and
(b) generate a message that is specific to the error, for each such
error.
compiler/prog_item.m:
Record two insts for each mutable, not one. The two differ in that
one is processed by equiv_type.m, the other isn't. If possibly,
add_mutable_aux_preds.m generates error messages from the latter,
because it preserves the original structure of the inst. This is
important, because having the compiler complain about e.g. a "unique"
inst in a mutable is confusing if the inst in the mutable is just "i1".
You want the error message to explain that "unique" is part of the
expansion of "i1", and this can only be done if the test works on an inst
in which equiv_type.m hasn't replaced "i1" with its definition.
Record two types for each mutable, not one, with the same difference,
for the same reason, for use by future checks on types in mutables.
Put the fields of item_mutable_infos into a more logical order.
compiler/equiv_type.m:
Process only one of each pair of type and inst fields in
item_mutable_infos.
compiler/get_dependencies.m:
compiler/module_qual.m:
compiler/parse_tree_out.m:
compiler/prog_io_mutable.m:
compiler/recompilation.version.m:
compiler/write_module_interface_files.m:
Conform to the change in prog_item.m.
tests/invalid/bad_mutable.err_exp:
tests/invalid/user_mutable.err_exp:
Expect the improved error messages.
Mercury
Mercury is a logic/functional programming language which combines the clarity and the expressiveness of declarative programming with advanced static analysis and error detection features.
More information is available on the website's about pages, in other README files in the source code repository, and in the documentation.
README files
The Mercury compiler has a number of different backends and works on different operating systems. Specific information is contained in individual README files:
-
Bootstrapping discusses how to get Mercury installed.
This is important as the Mercury compiler is written in Mercury.
-
C Low-level backend
This backend works well with GCC but also works with:
-
High-level backend targets
-
Platforms
-
Cross compilation
Other information
See the current release notes for the latest stable release. The history file is relevant if you want to find out more about the past development of Mercury. News lists any current or future enhancements (but this isn't always up-to-date). The limitations file lists a number of ways in which the Mercury implementation does not yet meet its goals.
Information for developers
If you are considering contributing to the Mercury project the website contains some documents that may be helpful. These include a document about contributions in general and specific information about contributing such as coding styles.
Contact
See our contact page.