... by eliminating the grade component that calls for the use of gcc nested
functions.
runtime/mercury_grade.h:
compiler/compute_grade.m:
Delete the gcc_nested_functions grade component, and the C macro
that specifies its presence, MR_USE_GCC_NESTED_FUNCTIONS.
scripts/canonical_grade.sh-subr:
scripts/init_grade_options.sh-subr:
scripts/mgnuc.in:
scripts/parse_grade_options.sh-subr:
Delete the code that parses the deleted grade component,
and delete the code that signals its absence in other grades.
compiler/options.m:
Delete the gcc_nested_functions grade option.
Delete also the gcc_local_labels option, since it was useful
only if gcc_nested_functions was set.
configure.ac:
Delete the code that sometimes added hl*_nest grades to the list of grades
to be installed.
Fix a bunch of comments.
compiler/compile_target_code.m:
compiler/handle_options.m:
compiler/mercury_compile_mlds_back_end.m:
compiler/ml_args_util.m:
compiler/ml_call_gen.m:
compiler/ml_code_util.m:
compiler/ml_commit_gen.m:
compiler/ml_gen_info.m:
compiler/mlds_to_c.m:
library/backjump.m:
library/exception.m:
runtime/mercury_hlc_types.h:
runtime/mercury_tabling.c:
runtime/mercury_tabling.h:
Delete code that was active only in grades with the deleted grade
component.
compiler/ml_accurate_gc.m:
compiler/notes/grade_library.html:
runtime/mercury_conf_param.h:
Delete mentions of the deleted grade component.
compiler/ml_code_gen.m:
Delete mentions of the deleted grade component, and a bunch of other
obsolete comments.
doc/user_guide.texi:
Fix a line break.
compiler/file_names.m:
Change the order of arguments of module_name_to_file_name and related
predicates to make it easier to construct closures from them. Delete
the previous higher-order-friendly versions, which the previous step
has made unnecessary.
compiler/compile_target_code.m:
compiler/elds_to_erlang.m:
compiler/export.m:
compiler/find_module.m:
compiler/generate_dep_d_files.m:
compiler/intermod.m:
compiler/llds_out_file.m:
compiler/make.m:
compiler/make.module_dep_file.m:
compiler/make.module_target.m:
compiler/make.program_target.m:
compiler/make.util.m:
compiler/mercury_compile_front_end.m:
compiler/mercury_compile_llds_back_end.m:
compiler/mercury_compile_main.m:
compiler/mercury_compile_middle_passes.m:
compiler/mercury_compile_mlds_back_end.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mmc_analysis.m:
compiler/mode_constraints.m:
compiler/module_cmds.m:
compiler/modules.m:
compiler/read_modules.m:
compiler/recompilation.check.m:
compiler/recompilation.usage.m:
compiler/write_deps_file.m:
compiler/write_module_interface_files.m:
compiler/xml_documentation.m:
Conform to the change above. In several places, this means replacing
explicit lambda expressions with simple partial application of the
relevant predicates.
configure.ac:
Add configure option --enable-sanitizers.
Mmake.common.in:
scripts/Mercury.config.in:
Add variables to be set when --enable-sanitizers is used.
scripts/mgnuc.in:
scripts/ml.in:
Pass sanitizer options to the C compiler and the linker.
compiler/options.m:
Add options --cflags-for-sanitizers and --linker-sanitizer-flags
for receiving the configuration.
Set --linker-trace-flags and --shlib-linker-trace-flags default
values to empty instead of "-g" (likely copy error).
compiler/compile_target_code.m:
Pass sanitizer options to the C compiler, and the linker when
building an executable or shared library.
runtime/Mmakefile:
trace/Mmakefile:
Pass sanitizer options to linker when building shared libraries.
README.sanitizers:
Add instructions.
With `--restricted-command-line' we generate a temporary archive file
name with `io.make_temp_file' then run `ar' to create the archive.
`ar' sees that the archive file already exists (it is empty), tries to
detect its format, and fails. The solution is to delete the temporary
file before calling `ar'. Fixes Mantis bug #424.
compiler/compile_target_code.m:
As above.
Add "mtmp" prefix to the temporary archive file name.
This fixes mantis bug #404.
compiler/compile_target_code.m:
compiler/make.dependencies.m:
Use the value of the rebuild option, not the op_mode, to make decisions
about executing operations that even when timestamps don't call for them.
This fixes the bug, because unlike the op_mode, the value of the option
isn't overridden by setting the invoked_by_mmc_make option when recomputing
the op_mode.
compiler/make.program_target.m:
compiler/make.util.m:
Reset the rebuild option, not the op_mode, since this is what matters now.
compiler/op_mode.m:
Take the value of the --rebuild option out of the op_mode, since it is not
needed *there* anymore.
Note that --rebuild still implies --make, so the rebuild option still does
play a role in selecting the op_mode. (This was the original motivation
for its inclusion in the op_mode in the first place.) This is why its value
matters when converting an op_mode back into its original option string.
Fix the copyright years.
compiler/options.m:
Since the rebuild option isn't stored in the op_mode anymore, give it back
its original, non-op_mode internal name.
compiler/handle_options.m:
compiler/mercury_compile_main.m:
Conform to the changes above.
compiler/file_util.m:
The predicates in this module that find the file containing a Mercury
module used to allow the caller to specify that if the file can be
successfully opened, then the current input stream should be set to
the resulting stream. This meant that callers had to save the original
current input stream *before* calling this predicate, and later restore it,
*without* anything in between that would signal to readers of the code
that the current input stream had ever been changed.
Replace each of these predicates with two predicates. One returns
the stream as an explicit part of an output argument, letting the caller
do with the stream what it wished (in some cases, that would mean
using it in I/O operations as *explicitly* passed parameters, which
would not require touching the identity of the current input stream),
giving it the responsibility to close the stream when it is done using it.
The other would close the stream immediately, not letting the caller know
that the file was ever opened. The two versions are distinguised both
by name and by return type.
compiler/find_module.m:
Make the same change to search_for_module_source. (This predicate was
the motivation for this change, because unlike the predicates in
file_util.m, its signature did NOT provide readers with any sort of clue
that the searched-for file would actually be opened, and that the
resulting stream would become the new current input stream.)
Clarify the code that tries to find the source file for a module
by dropping qualifiers from the module name by (a) giving the predicate
a more explicit name, and (b) separating the search from the code
that handles the failure of the search.
compiler/parse_module.m:
compiler/read_modules.m:
Change part of the interface between these two modules. This used to be
that code in read_modules.m passed closures to parse_module.m for it
to invoke, closures whose predicates were always one of the predicates
affected by the changes above. Simplify the interface by making
read_modules.m invoke those predicates directly, and simply pass
the results.
compiler/compile_target_code.m:
compiler/make.module_dep_file.m:
compiler/make.program_target.m:
compiler/mercury_compile_front_end.m:
compiler/mmc_analysis.m:
compiler/module_cmds.m:
compiler/options_file.m:
compiler/write_deps_file.m:
Conform to the changes above.
When libhwloc is available it is used by the low level C grades to determine
the number of processors available. I recently added similar support to the
high level C grades, but I neglected to add -lhwloc to the compiler's command
line in these grades. This patch fixes that.
compiler/compile_target_code.m:
Link to libhwloc in all parallel grades.
configure.ac:
Use the correct name for all instances of the same variable.
configure.ac:
The MinGW64 implementation of mkstemp is apparently broken, so
avoid using it for now.
compiler/compile_target_code.m:
Don't include an extra "." between the filename and the extension.
It is common to create a temporary file then open it for writing; or create
the temporary file, call another program, then open the file for reading.
This patch implements both these patterns as predicates in file_util.m
compiler/file_util.m:
Add new utility predicates.
compiler/compile_target_code.m:
compiler/fact_table.m:
compiler/make.util.m:
compiler/prog_event.m:
Make use of open_temp_input.
The make_temp predicates would throw an exception if they were unsuccessful,
New versions of make_temp/3 and make_temp/5 have been created (named
make_temp_file). make_temp/3 and make_temp/5 have been marked as obsolete.
make_temp_directory/3 and make_temp_directory/5 have been modified directly
as they are very new. This closes bug #408
Some routines in compiler/compile_target_code.m used the name returned by
make_temp and added a suffix before using the resulting file, this could
create unnecessary temporary files that I believe were never cleaned up. So
I've added a suffix argument to make_temp_file/5 and make_temp_directory/5
(now they're make_temp_file/6 and make_temp_directory/6).
library/io.m:
As above.
Remove out-of-date comment.
compiler/compile_target_code.m:
Conform to changes in io.m.
Use the new suffix argument to reduce the number of temporary files
created during linking.
compiler/fact_table.m:
compiler/make.module_target.m:
compiler/make.util.m:
compiler/module_cmds.m:
compiler/prog_event.m:
compiler/write_deps_file.m:
deep_profiler/conf.m:
Conform to changes in io.m.
Fix some comments (mostly in layout) in all the touched runtime headers.
runtime/mercury.h:
Simplify the error message on the one grade compatibility test
that is best kept out of mercury_grade.h, because it is next to
the cause of the potential incompatibility.
runtime/mercury_grade.h:
Add a comment about the grade compatibility test still in mercury.h.
Move all the grade compatibility tests from mercury_conf_param.h here.
Reword their error messages to talk directly about the user-visible
grade components (or the Mercury compiler options enabling them,
if there is no single grade component name for them) instead of the
names of the C macros representing them.
Group some related existing tests together.
runtime/mercury_conf_param.h:
Move all the grade compatibility tests here to mercury_grade.h.
compiler/compile_target_code.m:
Add a XXX.
The prog_data.m module is imported by most modules of the compiler; by
359 modules out of 488, to be exact. Yet it has many parts that most of
those 359 modules don't need. This diff puts those parts into four new
modules. The number of imports of these modules:
348 modules import prog_data.m
84 modules import prog_data_foreign.m
62 modules import prog_data_pragma.m
12 modules import prog_data_event.m
5 modules import prog_data_used_modules.m
compiler/prog_data_event.m:
compiler/prog_data_foreign.m:
compiler/prog_data_pragma.m:
compiler/prog_data_used_modules.m:
New modules. They contain the parts of the parse tree that deal
respectively with the specification of events and event sets,
interfacing to foreign languages, pragmas, and the sets of used
(i.e. not unused) modules.
compiler/prog_data.m:
Delete the stuff that is now in the new modules. Put the remaining parts
of the module into a logical order.
compiler/parse_tree.m:
compiler/notes/compiler_design.html:
Include and document the new modules.
compiler/globals.m:
Move a type here from prog_data.m, since this is where it belongs.
compiler/add_foreign_proc.m:
compiler/add_mutable_aux_preds.m:
compiler/add_pragma.m:
compiler/add_solver.m:
compiler/add_trail_ops.m:
compiler/call_gen.m:
compiler/code_gen.m:
compiler/code_loc_dep.m:
compiler/comp_unit_interface.m:
compiler/compile_target_code.m:
compiler/complexity.m:
compiler/continuation_info.m:
compiler/coverage_profiling.m:
compiler/ctgc.datastruct.m:
compiler/ctgc.livedata.m:
compiler/ctgc.selector.m:
compiler/deep_profiling.m:
compiler/dep_par_conj.m:
compiler/deps_map.m:
compiler/det_analysis.m:
compiler/det_report.m:
compiler/elds_to_erlang.m:
compiler/equiv_type.m:
compiler/erl_call_gen.m:
compiler/exception_analysis.m:
compiler/export.m:
compiler/fact_table.m:
compiler/foreign.m:
compiler/frameopt.m:
compiler/get_dependencies.m:
compiler/goal_form.m:
compiler/goal_util.m:
compiler/granularity.m:
compiler/hlds_goal.m:
compiler/hlds_module.m:
compiler/hlds_out_goal.m:
compiler/hlds_out_module.m:
compiler/hlds_out_pred.m:
compiler/hlds_pred.m:
compiler/inlining.m:
compiler/intermod.m:
compiler/ite_gen.m:
compiler/item_util.m:
compiler/jumpopt.m:
compiler/layout.m:
compiler/layout_out.m:
compiler/live_vars.m:
compiler/livemap.m:
compiler/llds.m:
compiler/llds_out_file.m:
compiler/llds_out_global.m:
compiler/llds_out_instr.m:
compiler/make.dependencies.m:
compiler/make.module_dep_file.m:
compiler/make_hlds.m:
compiler/make_hlds_warn.m:
compiler/mark_tail_calls.m:
compiler/mercury_compile_llds_back_end.m:
compiler/mercury_compile_main.m:
compiler/ml_call_gen.m:
compiler/ml_code_gen.m:
compiler/ml_code_util.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_proc_gen.m:
compiler/ml_tailcall.m:
compiler/ml_unify_gen.m:
compiler/mlds.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/modecheck_goal.m:
compiler/module_imports.m:
compiler/module_qual.m:
compiler/module_qual.qualify_items.m:
compiler/modules.m:
compiler/opt_debug.m:
compiler/par_conj_gen.m:
compiler/parse_pragma.m:
compiler/parse_tree_out_info.m:
compiler/parse_tree_out_pragma.m:
compiler/pd_cost.m:
compiler/polymorphism.m:
compiler/pragma_c_gen.m:
compiler/proc_gen.m:
compiler/prog_ctgc.m:
compiler/prog_event.m:
compiler/prog_foreign.m:
compiler/prog_item.m:
compiler/prog_out.m:
compiler/prog_util.m:
compiler/purity.m:
compiler/rbmm.points_to_analysis.m:
compiler/rbmm.points_to_graph.m:
compiler/simplify_goal_call.m:
compiler/simplify_goal_scope.m:
compiler/simplify_proc.m:
compiler/smm_common.m:
compiler/stack_layout.m:
compiler/structure_reuse.analysis.m:
compiler/structure_reuse.direct.choose_reuse.m:
compiler/structure_reuse.direct.detect_garbage.m:
compiler/structure_reuse.domain.m:
compiler/structure_reuse.indirect.m:
compiler/structure_sharing.analysis.m:
compiler/structure_sharing.domain.m:
compiler/table_gen.m:
compiler/tabling_analysis.m:
compiler/term_constr_build.m:
compiler/term_constr_initial.m:
compiler/term_constr_main.m:
compiler/term_constr_main_types.m:
compiler/term_constr_pass2.m:
compiler/term_constr_util.m:
compiler/term_errors.m:
compiler/term_pass1.m:
compiler/term_pass2.m:
compiler/term_traversal.m:
compiler/term_util.m:
compiler/termination.m:
compiler/trace_gen.m:
compiler/trailing_analysis.m:
compiler/type_constraints.m:
compiler/typecheck.m:
compiler/unique_modes.m:
compiler/unused_args.m:
compiler/unused_imports.m:
compiler/use_local_vars.m:
compiler/write_deps_file.m:
Conform to the changes above.
For picreg, this is only the first half of the change; it deletes code
that generates references to this grade component. When this diff has been
installed on all our machines, will come the second half, which will delete
the code that understands references to picreg. The delay is needed because
your current installed compiler is still generating such references.
runtime/mercury_grade.h:
Remove both regparm and picreg as grade components.
doc/user_guide.texi:
Remove the (commented out) documentation of picreg; regparm had
no documentation to delete.
runtime/mercury_std.h:
Remove the small bit of code that implemented regparm.
runtime/mercury_conf_param.h:
Don't define MR_PIC_REG.
runtime/machdeps/i386_regs.h:
runtime/mercury_conf_bootstrap.h:
Remove references to picreg.
scripts/canonical_grade.sh-subr:
scripts/init_grade_options.sh-subr:
scripts/mgnuc.in:
scripts/parse_grade_options.sh-subr:
Keep in place the code that accepts picreg grade components,
but make them do nothing. Mark such do-nothing code so that
it can be deleted when this first-half diff has been bootstrapped.
configure.ac:
Delete the autoconfigured variable EXT_FOR_LINK_WITH_PIC_OBJECTS,
which could be set to either 'lpic_o' or just 'o', because it is now
*always* the latter.
scripts/Mercury.config.bootstrap.in:
scripts/Mercury.config.in:
Remove code that transmitted the value of EXT_FOR_LINK_WITH_PIC_OBJECTS
to the compiler via the --link-with-pic-object-file-extension option.
compiler/options.m:
Keep the --link-with-pic-object-file-extension and --pic-reg options,
but mark them for deletion in the second half of this change.
compiler/compile_target_code.m:
Change the code that dealt with the value of the
--link-with-pic-object-file-extension and --pic-reg options to assume
that the former is always the same as the non-pic file extension,
and that --pic-reg is never needed. The former means that we don't need
to handle link_with_pic as a separate category of object files from
just plain non_pic.
compiler/compute_grade.m:
Keep accepting picreg grades, but mark the code that does this
for deletion.
compiler/make.program_target.m:
compiler/make.module_target.m:
compiler/make.program_target.m:
compiler/make.util.m:
Conform to the changes above.
The options that help determine the op_mode are only sort-of mutually
exclusive; in some cases, more than one can be set. Using the op_mode
instead of the options themselves means that we are using the result
of the process (in op_mode.m) that resolves conflicts between them.
Another benefit is that in some places in the code, many op_modes
have already been processed, which means that the set of remaining op_modes
is a reasonably small set.
compiler/options.m:
Give all the options that op_mode.m uses to compute the op_mode
new internal names. (The user-visible names are not affected.)
Each new internal name is the old internal name with an added
"only_opmode_" prefix, indicating that the option should not be used
for any purpose other than computing the op_mode.
Change the documentation of the --generate-module-order and --imports-graph
options. (See handle_options.m below for the reason.)
doc/user_guide.texi:
Change the documentation of the --generate-module-order and --imports-graph
options, as in compiler/options.m.
compiler/handle_options.m:
Delete implications that set the values of options that help decide the
op_mode, since those implications used to be executed *after* we decided
the op_mode. Replace each of their functionalities with something else.
For the implication from --rebuild to --make, the replacement is
new code in op_mode.m (see below).
For the implication from --invoked-by-mmc-make to --no-make,
the needed replacement code was already in op_mode.m.
For the implications from --generate-module-order and --imports-graph
to --generate-dependencies, do not replace them. Instead, document that
they are effective only if the op mode is generating dependencies.
This goes against the current documentation of --generate-module-order,
though not of --imports-graph (the help message for --imports-graph
is silent on its relationship with --generate-dependencies). However,
the new documented (and implemented) behavior is actually more useful,
since it allows both options to be specified in Mmakefiles or
Mercury.options files, have them be acted on when making dependencies,
but not get error messages about incompatible op mode options.
However, it does mean that "mmc --generate-module-order x.m" would
now try to compile x.m while ignoring the option, whereas previously
it would implicitly act as if the command line were "mmc
--generate-dependencies --generate-module-order x.m". And similarly
for --imports-graph.
Simplify the code that disables smart recompilation when it is not
relevant.
NEWS:
Mention the changes to --generate-module-order and --imports-graph.
compiler/op_mode.m:
Make the opm_top_make functor take an argument that says whether we
are forcing rebuilds or not. The --rebuild option implies we are;
the --make option without --rebuild implies we are not. This replaces
the deleted implication in handle_options.m.
Conform to the name changes in options.m.
compiler/add_type.m:
compiler/compile_target_code.m:
compiler/exception_analysis.m:
compiler/headvar_names.m:
compiler/hlds_module.m:
compiler/make.dependencies.m:
compiler/make.program_target.m:
compiler/make.util.m:
compiler/mark_tail_calls.m:
compiler/mercury_compile.m:
compiler/mercury_compile_front_end.m:
compiler/mercury_compile_llds_back_end.m:
compiler/mode_errors.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_constr_initial.m:
compiler/termination.m:
compiler/trailing_analysis.m:
compiler/unused_args.m:
Replace tests of op_mode options with tests of the op_mode itself.
In mercury_compile*.m, get the op_mode to the places that now need it.
In a few places in make.*.m, replace code that sets op_mode options
(temporarily, for the duration of an operation) with code that sets
the op_mode itself.
compiler/globals.m:
Add the now-needed capability to set the op_mode.
Doing 'sudo make install' on Linux with Java 7 or later results in the installed
standard library jars being owned by the root user (which is fine) and with
permissions 0600 (which is not). This is occurring because as part of building
the library jars we create a jar index using the 'jar -i' command. Doing so
creates a temporary file with the above permissions and the installed version
inherits those. Building the index is only useful for executable jars anyway
and the Mercury compiler never builds those, so the fix is to simply not build
the index.
This fix is due to Sebastian Godelet.
compiler/compile_target_code.m:
As above.
compiler/compute_grade.m:
New module containing all the code previously in handle_options.m
that concern grades.
compiler/libs.m:
compiler/notes/compiler_design.html:
Include and document the new module.
compiler/compiler_util.m:
Since both handle_options.m and compute_grade.m now need to be able
to record errors, move the predicates that handle_options.m used to use
for this purpose to this module, which already contains related predicates.
Generalize the moved predicates, so they can be used from phases other than
option processing.
compiler/handle_options.m
Remove the moved code.
compiler/exception_analysis.m:
compiler/file_names.m:
compiler/file_util.m:
compiler/implementation_defined_literals.m:
compiler/inst_user.m:
compiler/make.program_target.m:
compiler/mercury_compile.m:
compiler/mercury_compile_front_end.m:
compiler/module_cmds.m:
compiler/options.m:
compiler/tabling_analysis.m:
compiler/term_constr_fixpoint.m:
compiler/term_constr_initial.m:
compiler/term_constr_main.m:
compiler/termination.m:
compiler/trailing_analysis.m:
Conform to the above, and/or delete unneeded imports.
compiler/mlds_to_il.m:
compiler/mlds_to_ilasm.m:
compiler/mlds_to_managed.m:
compiler/il_peephole.m:
compiler/ilasm.m:
compiler/ilds.m:
Delete the modules making up the MLDS->IL code generator.
compiler/globals.m:
compiler/prog_data.m:
Delete IL as a target and foreign language.
compiler/prog_io_pragma.m:
Delete the max_stack_size/1 foreign proc attribute. This was only
ever required by the IL backend.
compiler/options.m
Delete options used for the IL backend.
compiler/write_deps_file.m:
Don't generate mmake targets for .il files etc.
compiler/*.m:
Conform to the above changes.
compiler/notes/compiler_design.html
compiler/notes/work_in_progress.html
Conform to the above changes.
library/*.m:
Delete IL foreign_proc and foreign_export pragmas.
README.DotNet:
Delete this file.
browser/Mmakefile:
compiler/Mmakefile:
deep_profiler/Mmakefile:
mdbcomp/Mmakefile:
mfilterjavac/Mmakefile:
profiler/Mmakefile:
runtime/Mmakefile:
slice/Mmakefile:
Conform the above changes.
configure.ac:
Don't check that IL is a supported foreign language when performing the
up-to-date check.
Delete the '--enable-dotnet-grades' option.
scripts/Mmake.vars.in:
Delete variables used for the IL backend (and in on case by the Aditi
backend).
scripts/Mercury.config.bootstrap.in:
scripts/Mercury.config.in:
scripts/Mmake.rules:
scripts/canonical_grade.sh-subr:
tools/bootcheck:
Delete stuff related to the 'il' and 'ilc' grades.
doc/reference_manual.texi:
Delete the documentation of the 'max_stack_size' option.
doc/user_guide.texi:
Delete stuff related to the IL backend.
tests/hard_coded/csharp_test.{m,exp}:
tests/invalid/foreign_type_missing.{m,err_exp}:
tests/valid/csharp_hello.m:
Delete these tests: they are no longer relevant.
tests/hard_coded/equality_pred_which_requires_boxing.m:
tests/hard_coded/foreign_import_module.m:
tests/hard_coded/foreign_import_module_2.m:
tests/hard_coded/foreign_type.m:
tests/hard_coded/foreign_type2.m:
tests/hard_coded/foreign_type3.m:
tests/hard_coded/intermod_foreign_type2.m:
tests/hard_coded/lp.m:
tests/hard_coded/user_compare.m:
tests/invalid/foreign_type_2.m:
tests/invalid/foreign_type_missing.{m,err_exp}:
tests/invalid/foreign_type_visibility.m:
tests/invalid/illtyped_compare.{m,err_exp}:
tests/submodules/external_unification_pred.m
tests/valid/big_foreign_type.m
tests/valid/solver_type_bug.m
tests/valid_seq/foreign_type_spec.m
tests/valid_seq/intermod_impure2.m
Delete IL foreign_procs where necessary.
tests/hard_coded/Mmakefile
tests/invalid/Mercury.options
tests/invalid/Mmakefile
tests/submodules/Mmakefile
tests/valid/Mercury.options
tests/valid/Mmake.valid.common
tests/valid/Mmakefile
tests/valid_seq/Mmakefile
tests/valid_seq/Mercury.options
Conform to the above changes.
compiler/prog_data.m:
A foreign_import_module_info structure used to record not just what
module's target language header file is imported in what target language,
but also a context associated with that import, which was set to the
context of the compiler-generated `:- pragma foreign_import_module'
declaration in the .opt file we read it in from. However, we never did
anything useful with this context, and took advantage of that fact
by setting that field to dummy values in pretty much all the
foreign_import_module_info structures created by the compiler.
Since the target language code we generate may need to import the same
target language header file for many different reasons, it is very
unlikely that there is ever going to be a *single* context we may
ever want to associate with the import of one header for one language.
Therefore delete the context field from foreign_import_module_infos.
After this deletion, there is no point in keeping around multiple
foreign_import_module_infos for the same target language / module name
combination. Instead of a set of such pairs, use a representation
that stores a set of imported module names for each of the possible
target languages, since this makes operations faster.
Provide predicates for the operations on the new foreign_import_modules
type that are needed in more than one place.
compiler/prog_item.m:
Avoid having the pragma_info_foreign_import_module type being a duplicate
of the now slimmed-down foreign_import_module_info type by making the
former a wrapper around the latter. (One could replace the former
by the latter, but the current arrangement costs nothing at runtime,
and keeps the documentation of this pragma next to the documentation
of the related pragmas.)
compiler/add_pragma.m:
compiler/comp_unit_interface.m:
compiler/compile_target_code.m:
compiler/deps_map.m:
compiler/foreign.m:
compiler/globals.m:
compiler/hlds_module.m:
compiler/make.dependencies.m:
compiler/make.module_dep_file.m:
compiler/mercury_compile_llds_back_end.m:
compiler/ml_proc_gen.m:
compiler/mlds_to_c.m:
compiler/module_imports.m:
compiler/modules.m:
compiler/parse_tree_out_pragma.m:
compiler/prog_foreign.m:
compiler/prog_io_pragma.m:
compiler/write_deps_file.m:
Conform to the above changes. In many places, we can avoid such things as
(a) filtering all foreign_import_module_infos looking for given languages,
or (b) converting from cords to lists to sets, operating on the sets,
and converting the result back to lists and maybe to cords.
compiler/intermod.m:
As above, but also order the source code of the main predicates
of this module in the same order as their invocation, and give some
of them more meaningful names.
If a module has two or more import_module or use_module declarations
for the same module, (typically, but not always, one being in its interface
and one in its implementation), generate an informational message about
each redundant declaration if --warn-unused-imports is enabled.
compiler/hlds_module.m:
We used to record the set of imported/used modules, and the set of
modules imported/used in the interface of the current module. However,
these sets
- did not record the distinction between imports and uses;
- did not allow distinction between single and multiple imports/uses;
- did not record the locations of the imports/uses.
The first distinction was needed only by module_qual.m, which *did*
pay attention to it; the other two were not needed at all.
To generate messages for imports/uses shadowing other imports/uses,
we need all three, so change the data structure storing such information
for *direct* imports to one that records all three of the above kinds
of information. (For imports made by read-in interface and optimization
files, the old set of modules approach is fine, and this diff leaves
the set of thus *indirectly* imported module names alone.)
compiler/unused_imports.m:
Use the extra information now available to generate a
severity_informational message about any import or use that is made
redundant by an earlier, more general import or use.
Fix two bugs in the code that generated warnings for just plain unused
modules.
(1) It did not consider that a use of the builtin type char justified
an import of char.m, but without that import, the type is not visible.
(2) It scanned cons_ids in goals in procedure bodies, but did not scan
cons_ids that have been put into the const_struct_db. (I did not update
the code here when I added the const_struct_db.)
Also, add a (hopefully temporary) workaround for a bug in
make_hlds_passes.m, which is noted below.
However, there are at least three problems that prevent us from enabling
--warn-unused-imports by default.
(1) In some places, the import of a module is used only by clauses for
a predicate that also has foreign procs. When compiled in a grade that
selects one of those foreign_procs as the implementation of the predicate,
the clauses are discarded *without* being added to the HLDS at all.
This leads unused_imports.m to generate an uncalled-for warning in such
cases. To fix this, we would need to preserve the Mercury clauses for
*all* predicates, even those with foreign procs, and do all the semantic
checks on them before throwing them away. (I tried to do this once, and
failed, but the task should be easier after the item list change.)
(2) We have two pieces of code to generate import warnings. The one in
unused_imports.m operates on the HLDS after type and mode checking,
while module_qual.m operates on the parse tree before the creation of
the HLDS. The former is more powerful, since it knows e.g. what types and
modes are used in the bodies of predicates, and hence can generate warnings
about an import being unused *anywhere* in a module, as opposed to just
unused in its interface.
If --warn-unused-imports is enabled, we will get two separate set of
reports about an interface import being unused in the interface,
*unless* we get a type or mode error, in which case unused_imports.m
won't be invoked. But in case we do get such errors, we don't want to
throw away the warnings from module_qual.m. We could store them and
throw them away only after we know we won't need them, or just get
the two modules to generate identical error_specs for each warning,
so that the sort_and_remove_dups of the error specs will do the
throwing away for us for free, if we get that far.
(3) The valid/bug100.m test case was added as a regression test for a bug
that was fixed in module_qual.m. However the bug is still present in
unused_imports.m.
compiler/make_hlds_passes.m:
Give hlds_module.m the extra information it now needs for each item_avail.
Add an XXX for a bug that cannot be fixed right now: the setting of
the status of abstract instances to abstract_imported. (The "abstract"
part is correct; the "imported" part may not be.)
compiler/intermod.m:
compiler/try_expand.m:
compiler/xml_documentation.m:
Conform to the change in hlds_module.m.
compiler/module_qual.m:
Update the documentation of the relationship of this module
with unused_imports.m.
compiler/hlds_data.m:
Document a problem with the status of instance definitions.
compiler/hlds_out_module.m:
Update the code that prints out the module_info to conform to the change
to hlds_module.m.
Print status information about instances, which was needed to diagnose
one of the bugs in unused_imports.m. Format the output for instances
nicer.
compiler/prog_item.m:
Add a convenience predicate.
compiler/prog_data.m:
Remove a type synonym that makes things harder to understand, not easier.
compiler/modules.m:
Delete an XXX that asks for the feature this diff implements.
Add another XXX about how that feature could be improved.
compiler/Mercury.options.m:
Add some more modules to the list of modules on which the compiler
should be invoked with --no-warn-unused-imports.
compiler/*.m:
library/*.m:
mdbcomp/*.m:
browser/*.m:
deep_profiler/*.m:
mfilterjavac/*.m:
Delete unneeded imports. Many of these shadow other imports, and some
are just plain unneeded, as shown by --warn-unused-imports. In a few
modules, there were a *lot* of unneeded imports, but most had just
one or two.
In a few cases, removing an import from a module, because it *itself*
does not need it, required adding that same import to those of its
submodules which *do* need it.
In a few cases, conform to other changes above.
tests/invalid/Mercury.options:
Test the generation of messages about import shadowing on the existing
import_in_parent.m test case (although it was also tested very thoroughly
when giving me the information needed for the deletion of all the
unneeded imports above).
tests/*/*.{m,*exp}:
Delete unneeded imports, and update any expected error messages
to expect the now-smaller line numbers.
After my earlier changes to the item list, we used module_defns for only
two things: recording when one module includes another, and recording
when one module imports or uses another. After this diff, both those
pieces of information are stored separately in each item block.
This has two benefits.
The first benefit is that it allows us to use the type system to enforce
structural invariants about where include_module, import_module and use_module
declarations may appear. The one invariant that we now enforce is that
optimization files may not contain either include_module or import_module
declarations, though they may contain use_module declarations. I suspect that
there are also similar invariants about interface files, but finding them
requires something like this change.
The second benefit is that it allows traversals of item blocks to scan
only the part of the item block that may contain the object of interest.
While reading in interface and optimization files, we used to scan the
full item list several times to find included and imported modules; those
scans can now look at just the relevant information. Since the item lists
that need to be processed usually include all the declarations in a
substantial number of other modules, including some (such as list.m) that
have LOTS of declarations, the speedup can be substantial. On tools/speedtest,
the speedup is 1.5%.
compiler/prog_item.m:
Make the change described above.
Provide utility predicates on the new types representing include_module,
import_module and use_module declarations.
Move an old utility predicate from here to prog_io.m, since only prog_io.m
uses it.
compiler/module_imports.m:
Several fields of the module_imports type contained sets of module names,
but stored them as lists. Change these to actual sets, to distinguish them
from the lists whose order is actually important. (Basically, the order
of processing .trans_opt files is important, but the order in which
we read in .int0, .int3, .int2, .int and .opt files isn't.) In several
places, this also avoids the need for conversions of lists to sets
for set operations, and then back to lists.
compiler/modules.m:
This module had several predicates that processed list of module names.
Make these operate on sets of module names instead, and break each of them
into two predicates: one that decides whether there is a next module name,
and if yes whether it has been processed already, and one to do the actual
processing if needed. This avoid the need for excessive indentation.
The code that discovers what other modules' interface files may need
to be read is now simpler due to the updated item_block structure.
Remove the submodule whose job it was to discover what modules are included
in items or item blocks, since that task has now become trivial, and is
now done by a utility predicate in prog_item.m. Since this was the second
last submodule (of the original eight), the last submodule is now the
whole module. Therefore this module now has significantly greater cohesion
than it had before.
compiler/write_module_interface_files.m:
compiler/prog_io_item.m:
Parse include_module, import_module and use_module declarations as
markers, not as items.
compiler/prog_io.m:
Expect include_module, import_module and use_module declarations as
markers, not as items.
compiler/split_parse_tree_src.m:
Discover included submodules more simply with the updated item_block
structure.
compiler/compile_target_code.m:
Put the arguments of the predicates in this module in a more standard
order.
compiler/recompilation.version.m:
Conform to the above changes. Note a possible bug.
Use a bespoke type to replace some bools.
compiler/check_raw_comp_unit.m:
compiler/comp_unit_interface.m:
compiler/deps_map.m:
compiler/equiv_type.m:
compiler/generate_dep_d_files.m:
compiler/get_dependencies.m:
compiler/hlds_module.m:
compiler/intermod.m:
compiler/item_util.m:
compiler/make.dependencies.m:
compiler/make.module_dep_file.m:
compiler/make.module_target.m:
compiler/make.program_target.m:
compiler/make_hlds_passes.m:
compiler/mercury_compile.m:
compiler/mercury_compile_llds_back_end.m:
compiler/mercury_to_mercury.m:
compiler/module_deps_graph.m:
compiler/module_qual.m:
compiler/prog_io_find.m:
compiler/read_modules.m:
compiler/recompilation.check.m:
compiler/recompilation.usage.m:
compiler/trans_opt.m:
compiler/write_deps_file.m:
Conform to the above changes.
mdbcomp/sym_name.m:
Provide a utility predicate to get the set of ancestors of a module
as a set as well as a list.
tests/invalid/exported_unify3.err_exp:
tests/invalid/ii_parent.ii_child.err_exp:
Update the expected error messages, which refer to line numbers in
.int0 files, which have now changed, as we now put all import_module
declarations before ordinary items.
(Error messages shouldn't refer to automatically generated files,
but that is a separate concern.)
When --use-grade-subdirs was enabled the compiler was incorrectly looking for
wrapper batch files generated in the Java grade in the 'bin' directory rather
than the 'bats' directory. This was due to the file extension for the wrapper
scripts not being set correctly; the fix is to set it correctly.
(Patch from Sebastian Godelet.)
compiler/compile_target_code.m:
As above.
Recent Java compilers have started aborting if any -J options occur inside
@files. Since --restricted-command-line implies the use of @files, we need to
filter out any -J options to javac and ensure that they do not end up inside an
@file when --restricted-command-line is enabled.
compiler/compile_target_code.m:
When gathering the flags for the Java compiler, separate out any
-J flags and ensure that they do not get placed in an @file.
Fix problems that occur when generating executables in the C# and Java grades
with --use-grade-subdirs enabled, namely:
* the compiler aborts when it tries to build the launcher script for a Java
grade executable.
* the compiler does not place generated Java archive files under the Mercury
subdirectory.
* in C# grades, the compiler always places the launcher script in the user's
directory rather than under the Mercury subdirectory.
The above problems were mainly caused by the "link" step for executables being
incorrect for the C# and Java backends. In other grades, the link step
consists of:
1. use the linker to create the executable in C grades, or generate a launcher
script in the Erlang grade. This executable or script is placed under the
Mercury subdirectory.
2. create a symlink (or copy if --no-use-symlinks is enabled) the executable
or script into the user's directory.
This does not work for the C# and Java backends since their principle "link
target" is not the launcher script (as is the case with the Erlang backend),
but a ".exe" or ".jar" file. The launcher script is generated as a side-effect
of creating that. (This has long been the case for the C# backend and has
recently become the case for the Java backend since we moved to generating
archives for executables.) The correct sequence of "linking" steps for these
two backends should be:
1. create the .exe or .jar under the Mercury subdirectory.
2. create the launcher script file, if required, under the Mercury subdirectory.
3. symlink or copy the .exe or .jar file to the user's directory.
4. symlink or copy the launcher script to the user's directory, if required.
This diff makes the compiler carry out the latter sequence of steps for the C#
and Java backends.
compiler/compile_target_code.m:
Make the executable target for the Java backend work more like that of
the C# backend. Merge it with the code for handling library targets in the
Java backend since, apart from the creation of the launcher script, it is
identical.
We may need to do multiple create symlink or copy operations when
creating an executable using the C# or Java backends: one for the
".exe" or ".jar" and another for the launcher script.
Separate out the code for determining the launcher script extension into
a new function.
compiler/make.util.m:
Conform to the above change.
Add an XXX comment about the Erlang backend; I'll look into this
separately.
compiler/file_names.m:
Update the list of architecture or grade dependent files to include those
with the extensions ".jar" and ".bat", and also those files with no
extension at all. (For Mercury, the latter will either be launcher scripts
or executables.) Not covering these cases had a number of untoward
effects: ".jar" files were not placed in grade specific directories and the
launcher script in the C# grade was always placed in the user's directory.
compiler/module_cmds.m:
Create any required subdirectories under the Mercury directory when
generating launcher scripts.
If --verbose-commands is enabled, then print a message when creating
a symlink or copying a file. I needed this when debugging the above
problems.
Use io.format/4 to generate an error message rather than multiple
calls to io.write_string/3.
When building an executable in the Java grade, the Mercury compiler generates
all the class files in the Mercury subdirectory and then generates a wrapper
script or batch file that points towards these class files. This makes
deploying executables built in the Java grade rather awkward. This change
makes the Mercury compiler package up all the class files for an executable
into a JAR file and modifies the wrapper scripts to point to this JAR file.
NOTE: the JAR file we generate cannot be executed with 'java -jar ...'. This
is because in that mode of operation the Java interpreter ignores all user
classpath settings, such as those that tell the interpreter where the Mercury
standard library is. (We could support this mode of operation by setting any
required library classpath directories in the archive's manifest, but that
would mean either hardcoding installation specific directories in the manifest
or copying any required .jars to a known location relative to the executable's
class files. Generating such self-contained archives may be useful in some
cases, but it is not something this change addresses.)
compiler/compile_target_code.m:
Rename the link target type for Java executables.
Add a predicate for creating Java "executables": this involves generating
an archive (as we do for libraries) and then generating the wrapper script
or batch file.
Simplify some code that generates an error message.
compiler/module_cmds.m:
Change the wrapper scripts for Java executables to point towards
the .jar file generated instead of the class files in the Mercury
subdirectory.
Ditto for the wrapper batch files.
compiler/make.m:
compiler/make.program_target.m:
compiler/make.util.m:
Conform to the above changes.
README.Java:
Mention that class files for the executable are packaged up in
an archive.
NEWS:
Announce this change.
compiler/file_names.m:
Linking a program with other Mercury libraries (using -ml) was borken
because Mercury didn't recognize .lib files as libraries and therefore
searched for them in an incorrect location.
compiler/compile_target_code.m:
MSVC doesn't support the -l option for linking with .dll files. Instead
a corresponding .lib file should appear on the command line without an
"-l" prefix.
compiler/hlds_module.m:
Put related fields of the module_sub_info next to each other.
Some of those fields contained lists that were built reversed,
in order to avoid O(N^2) behavior when repeatedly adding new items
to the end of the list. Replace these with cords, which did not exist
when those fields were first added.
Give some fields and their getter/setter predicates more descriptive
names.
Separate out both the declarations and definitions of the getter and
setter predicates, and put them into the same order as the (updated)
order of the fields. Put the utility predicates (those that are more
complicated than just getters or setters) into an order based on
what fields they work on, following the same order.
Improve the operation of some of the utility predicates, e.g. replacing
a nondet predicate with a det predicate returning a set.
Delete an unused type.
Conform to the changes in the modules imported by hlds_module.m,
e.g. pred_table.m, prog_data.m and prog_foreign.m.
compiler/pred_table.m:
We used to store the set of valid pred ids as two lists, again to avoid
O(N^2) behavior. Replace the two lists with a set. This allows
looking up the set *without* updating the pred_table, or, when
the pred_table is within the module_info, updating the module_info.
Instead of allowing callers to replace the set of valid pred ids wholesale,
enforce the documented invariant on that set by only allowing deletions.
Conform to the changes above.
compiler/add_pragma.m:
compiler/bytecode_gen.m:
compiler/check_typeclass.m:
compiler/compile_target_code.m:
compiler/cse_detection.m:
compiler/dead_proc_elim.m:
compiler/deep_profiling.m:
compiler/dep_par_conj.m:
compiler/dependency_graph.m:
compiler/deps_map.m:
compiler/det_analysis.m:
compiler/distance_granularity.m:
compiler/equiv_type_hlds.m:
compiler/erl_code_gen.m:
compiler/exception_analysis.m:
compiler/export.m:
compiler/float_regs.m:
compiler/foreign.m:
compiler/higher_order.m:
compiler/hlds_module.m:
compiler/inlining.m:
compiler/intermod.m:
compiler/introduce_parallelism.m:
compiler/lambda.m:
compiler/liveness.m:
Conform to the changes above.
In many places, the change to how the valid pred ids are stored
allows us to avoid creating new module_infos.
In some places, fix style issues I noticed while working on the above.
compiler/llds.m:
compiler/mercury_compile_llds_back_end.m:
Conform to the changes above.
Move a type from llds.m to mercury_compile_llds_back_end.m, since
only the latter uses it.
compiler/prog_data.m:
compiler/prog_foreign.m:
Replace some types that used to hold reversed lists with cords.
In prog_foreign.m, represent the two kinds of foreign code that
do NOT define procedures with similarly named types.
Delete a type (user_foreign_code) that duplicated another type.
Replace an equivalence type with a notag type, for safety.
compiler/recompilation.usage.m:
compiler/typecheck.m:
compiler/typecheck_errors.m:
Now that we have direct access to the set of visible modules,
simplify the logic of some code dealing with those modules.
compiler/module_imports.m:
Put some related fields next to each other.
compiler/llds_out_file.m:
compiler/make.dependencies.m:
compiler/make.module_dep_file.m:
compiler/make_hlds_passes.m:
compiler/mark_tail_calls.m:
compiler/mercury_compile_front_end.m:
compiler/mercury_compile_middle_passes.m:
compiler/ml_proc_gen.m:
compiler/mlds.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_il.m:
compiler/mlds_to_java.m:
compiler/mlds_to_managed.m:
compiler/mode_constraints.m:
compiler/modes.m:
compiler/modules.m:
compiler/passes_aux.m:
compiler/polymorphism.m:
compiler/post_typecheck.m:
compiler/pred_table.m:
compiler/proc_gen.m:
compiler/prog_item.m:
compiler/purity.m:
compiler/rbmm.condition_renaming.m:
compiler/rbmm.execution_path.m:
compiler/rbmm.live_region_analysis.m:
compiler/rbmm.live_variable_analysis.m:
compiler/rbmm.points_to_analysis.m:
compiler/rbmm.region_arguments.m:
compiler/rbmm.region_instruction.m:
compiler/ssdebug.m:
compiler/stm_expand.m:
compiler/stratify.m:
compiler/structure_reuse.analysis.m:
compiler/structure_reuse.direct.m:
compiler/structure_reuse.domain.m:
compiler/structure_sharing.analysis.m:
compiler/structure_sharing.domain.m:
compiler/switch_detection.m:
compiler/tabling_analysis.m:
compiler/term_constr_initial.m:
compiler/term_constr_main.m:
compiler/termination.m:
compiler/trailing_analysis.m:
compiler/trans_opt.m:
compiler/try_expand.m:
compiler/type_constraints.m:
compiler/untupling.m:
compiler/unused_args.m:
compiler/write_deps_file.m:
Add two new options for querying the compiler. The first new option,
--output-target-arch, prints the target architecture. This is useful in
situations where you are working directly with the contents of the Mercury
subdirectory and --use-grade-subdirs is enabled. (The directory names
generated by --use-grade-subdirs include the target architecture.) The second
new option, --output-class-dir, deals with a more specific instance of the
above. It prints out the name of the directory in which the Mercury compiler
places generated Java class files.
Replace the use of 'fullarch' by 'target_arch' throughout the compiler.
(We still currently support '--fullarch' as a synonym for '--target-arch'
but that too will eventually be dropped.)
compiler/options.m:
Add the new options.
compiler/mercury_compile.m:
Implement the new options.
s/fullarch/target_arch/
Add an XXX comment about an inaccurate error message.
compiler/handle_options.m:
compiler/compile_target_code.m:
compiler/file_names.m:
compiler/make.program_target.m:
Conform to the above changes.
doc/user_guide.texi:
Document the new options.
Drop support for lcc as a C compiler. lcc itself does not seem to have been
updated since around 2010 and Mercury's support for it has not been updated for
quite a while before that.
Derivatives of lcc, for example lcc-win32, would almost certainly need to be
treated separately anyway, so this change doesn't affect them (i.e. they are
already not supported).
configure.ac:
m4/mercury.m4:
Do not recognise lcc as a C compiler.
Unrelated change: remove residual support for a.out executables on Linux.
scripts/mgnuc_file_opts.sh-subr:
Do not define the macros __EXTENSIONS__ and _GNU_SOURCE if the mgnuc script
is invoked with --no-ansi. This was originally done to support lcc on Linux.
Doing so on *all* systems as this code actually does is not a good idea.
(If it becomes necessary to reinstate this behaviour on some system, it
should be controlled from the configure script not here.)
runtime/mercury_wrapper.c:
Delete a workaround for lcc.
scripts/mgnuc.in:
scripts/ml.in:
compiler/compile_target_code.m:
compiler/handle_options.m:
compiler/globals.m:
compiler/ml_code_gen.m:
Delete support for lcc.
README.lcc:
Delete this file.
compiler/*.m:
Module qualify the end_module declarations. In some cases, add them.
compiler/table_gen.m:
Remove an unused predicate, and inline another in the only place
where it is used.
compiler/add_pragma.m:
Give some predicates more meaningful names.
mdbcomp/sym_name.m:
New module, containing the part of the old prim_data.m that
dealt with sym_names.
mdbcomp/builtin_modules.m:
New module, containing the part of the old prim_data.m that
dealt with builtin modules.
mdbcomp/prim_data.m:
Remove the things that are now in the two new modules.
mdbcomp/mdbcomp.m:
deep_proiler/Mmakefile:
slice/Mmakefile:
Add the two new modules.
browser/*.m:
compiler/*.m:
deep_proiler/*.m:
mdbcomp/*.m:
slice/*.m:
Conform to the above changes.
Library installation with mmc --make sometimes attempt to install libraries in
non-existent grades, for example java.par or java.trseg. The cause of this
problem is some left over code from the GCC backend, in particular the
high-level C base grade components imply multiple possible target languages, C
and asm. This is a problem because of the XXX in the predicate
convert_grade_option/3, where we only update the current target language if the
base grade component has a single target language associated with it.
For example, when a library is being installed in the grades java and hlc.par.gc and
we are at the step where we install it in the hlc.par.gc grade (second, since the
libgrade list is sorted), we build up the following command line for the mmc subprocess
that will do the installation in that grade:
mmc --invoked-by-mmc-make ... --make \
--grade java --use-grade-subdirs \
--grade hlc.par.gc --use-grade-subdirs \
--java-only --use-subdirs <target>
(XXX I don't know why we need to keep repeating --use-grade-subdirs like this,
or why we have to pass --use-subdirs at all given that it is implied by
--use-grade-subdirs. Or what the rationale for passing all the --grade options
to the subprocess is.)
When the option "--grade java" is processed the target language will be set to
Java, but because of the XXX in convert_grade_option/3, the target language
will not be set to C when the option "--grade hlc.par.gc" is subsequently
processed, hence the compiler will attempt to install the library in the
non-existent grade java.par. (Since --target java implies automatic GC,
the .gc component will vanish.)
The fix is to remove the asm target language for the high-level C base grade
components.
Additionally, remove other left over code for supporting --target asm.
compiler/handle_options.m:
Delete the "asm" target language for the high-level C base grade
components.
compiler/make.m:
compiler/globals.m:
compiler/add_pragma.m:
compiler/write_deps_file.m:
Delete references to "--target asm" and update some other comments
where necessary.
compiler/modules.m:
Delete two unused predicate that were only required by the GCC backend.
compiler/compile_target_code.m:
Delete the unused predicate assemble/7 that was only required by the
GCC backend.
compiler/mlds_to_c.m:
Add an XXX comment about some code that was required to support
"--target asm".
NEWS:
Announce the fix.
When --restricted-command-line is enabled, we try to shorten the link
command by creating a temporary archive of object files, including files
specified with --link-object. --link-object can also be used to specify
archives (.a) to link with, which results in nested archives in the
temporary archive. The linker does not look for object files in nested
archives so it does not work as intended.
compiler/compile_target_code.m:
Create the temporary archive for --restricted-command-line
consisting of only the file names in ObjectsList with known
object file extensions. Pass any other names in ObjectsList
to the link command directly.
As Tomas By's recent emails suggest, this support is doing more harm than good,
by falsely implying to people that MPS is a viable alternative to the Boehm
collector. The MPS collector was only ever experimental, and never performed
as well as Boehm. MPS isn't even in the git repository on git hub. It was
stored in a separate CVS repository on mundula, and (as far as I know)
wasn't carried over to github. The code of MPS was last touched a long time
ago; I would be surprised if it worked on today's systems without changes.
Mmake.common.in:
Mmake.workspace:
RESERVED_MACRO_NAMES:
boehm_gc/Mmakefile:
compiler/add_pragma.m:
compiler/compile_target_code.m:
compiler/globals.m:
compiler/handle_options.m:
compiler/mercury_compile_mlds_back_end.m:
compiler/mlds_to_c.m:
compiler/options.m:
compiler/peephole.m:
doc/user_guide.texi:
library/benchmarking.m:
runtime/Mmakefile.m:
runtime/mercury.h:
runtime/mercury_conf_param.h:
runtime/mercury_grade.h:
runtime/mercury_heap.h:
runtime/mercury_init.h:
runtime/mercury_memory.h:
runtime/mercury_wrapper.[ch]:
scripts/canonical_grade.sh-subr:
scripts/init_grade_options.sh-subr:
scripts/mgnuc.in:
scripts/ml.in:
scripts/parse_grade_options.sh-subr:
util/mkinit.c:
Remove all references to MPS.
No progress has been made on the LLDS->x86_64 backend since the initial work on
it and it is now more have a maintenance headache then anything else.
compiler/llds_to_x86_64.m:
compiler/llds_to_x86_64_out.m:
compiler/x86_64_instrs.m:
compiler/x86_64_out.m:
compiler/x86_64_regs.m:
Delete these modules.
compiler/globals.m:
Delete the x86_64 target type.
compiler/*.m:
Conform to the above changes.
Stripping executables on Mac OS X that were built with --mercury-linkage=shared
was resulting in the symbols for the global variables introduced for runtime
trace goal env flags being incorrectly removed. We need to pass the "-x" flag
to strip to prevent this happening. This diff adds the ability to pass
different flags to strip depending on the value of --mercury-linkage.
compiler/options.m:
Add two new options, --strip-executable-{shared,static}-flags, that
specify what flags are passed to the strip command when --mercury-linkage
is set to shared or static respectively.
Add a new option to test that the compiler is sufficiently up-to-date.
compiler/compile_target_code.m:
Implement the new options.
doc/user_guide.texi:
Document the new options.
NEWS:
Adjust the entry for the --strip-executable-command option to mention
the additional two new options.
The generated shell script to launch C# executables did not use absolute
paths. The C# and Java shell scripts were missing some variable
quoting, leading to problems with paths containing spaces.
compiler/compile_target_code.m:
Assign the script directory to DIR and use that to launch the
CLI interpreter.
Quote the CLI_INTERPRETER and executable filename.
compiler/module_cmds.m:
Quote Mercury-generated CLASSPATH in case the directory contains
spaces.
Make DIR absolute in case the script is invoked from a
subdirectory.
We had stopped passing the linker strip flag on Mac OS X because it had
become deprecated and useless there, but we can still strip the binary
with the `strip' tool.
This commit changes compile_target_code.m to do so, but NOT the
`ml' shell script.
compiler/options.m:
doc/user_guide.texi:
Add option --strip-executable-command.
configure.ac:
scripts/Mercury.config.in:
Set --strip-executable-command="strip" on Darwin platforms,
or an empty string elsewhere.
compiler/compile_target_code.m:
Invoke the --strip-executable-command separately after linking
an executable if necessary.
scripts/ml.in:
Fix a bug: use configured value of LD_STRIP_FLAG instead of
assuming "-s".
The "system" environment type is the environment type that external programs
invoked by the Mercury compiler (e.g. the C compiler) are run in. That is, it
is the environment type that you get when you run a command use the C standard
library's system() function. (Or equivalently, the Mercury standard library
predicate io.call_system/4.)
On sane operating systems this is identical to the host environment type. On
native Windows**, the system environment is whatever command interpreter the
environment variable COMSPEC is pointing to (by default, cmd.exe), regardless
of what value the Mercury option --host-env-type has. For example. if
--host-env-type is set to "msys" or "powershell" the system environment is
cmd.exe. The new option allows us to fully describe to the compiler which
environment types we intend it to interact with. Not being able to specify
this information has been one of the things preventing the powershell
environment from working properly.
** that is, Windows where the Mercury compiler is a native Windows executable,
so not on Cygwin when compiled against cygwin.dll, but on MinGW/MSYS.
compiler/options.m:
Add a new option, --system-env-type, which allows the "system"
environment to be specified.
Make the --env-type option also set the system environment type
as well as the host and target environment types.
compiler/handle_options.m:
Handle the new option. Make --system-env-type default to the value
of --host-env-type if the former is not given on the command line.
compiler/compile_target_code.m:
Use the system env type in place of the host env type in spots where
the former is what is actually meant.
compiler/globals.m:
Add a slot to the globals structure to hold the system environment
type.
doc/user_guide.texi:
Document the new option.
When printing the list of link library flags, the Mercury compiler would
attempt to perform any shell escapes required by the current shell**. This was
causing trouble if one of the libraries involved was libstdc++ and the output
of `--output-link-library-flags' was used in a shell script, for example:
LIB_LD_FLAGS=`$MMC --library stdc++ --output-library-flags`
This results in LIB_LD_FLAGS containing:
"-lstdc++" -lmer_std -lmer_rt -lgc -lm
And Doing something like this,
$CXX -o foo $OBJS $LIB_LD_FLAGS
would then result in a error, as "-lstdc++" would be treated by the C++
compiler as an argument not an option. This particular use case is fairly
common when using Mercury stand-alone interfaces.
The solution implemented by this change is to output the link library options
as-is when the compiler is invoked with `--output-link-library-flags' (i.e. do
not attempt to do any shell escapes). If, for some reason, the library names
do require shell escapes then doing so is the user's problem.
(There's not much the compiler can do anywayw, since it doesn't know how the
user is going to use the output generated by `--output-library-link-flags'.)
** there's a deeper issue here that the compiler's notion of the
"current shell" is not very good in some spots -- I'm thinking specifically of
the the function quote_arg/1 in compiler/options.m. Ideally, that function
should use the current setting of `--host-env-type' and not try to guess based
on whether dir.use_windows_paths/0 succeeds or not, however that's a problem
for a separate change.
compiler/compile_target_code.m;
Do not attempt to insert shell escapes into the link library options
when invoked with --output-library-link-flags.
Print a newline after the output from --output-library-link-flags.
The new --mfilterjavac option is used to specify a program to filter javac's
output in order to re-write the locations of errors created by Java foreign
code.
compiler/options.m:
Add the new option.
compiler/compile_target_code.m:
Handle the new option.
Add a new option, --cstack-reserve-size, that specifies the amount of virtual
memory that should be reserved for the stack in executables on Windows systems.
This is useful for non-trivial programs that use the high-level C backend since
they often bump into the default 1Mb limit.
compiler/options.m::
Add the new option.
compiler/compile_target_code.m:
Pass the appropriate flags to the linker if the new option is given.
doc/user_guide.texi:
Document the new option.
NEWS:
Announce the new option.
Add a new option, `--sign-assembly', to the Mercury compiler that causes it to
sign library assemblies generated by the C# backend with a user-specified
strong name. There was an existing undocumented option of the same name for
use by the IL backend; it has been renamed to --il-sign-assembly.
compiler/options.m:
Add the new option.
Rename the existing `--sign-assembly' option to `--il-sign-assembly'.
compiler/compile_target_code.m:
Optionally sign library assemblies.
compiler/mlds_to_il.m:
compiler/mlds_to_managed.m:
compiler/write_deps_file.m:
Conform to the above changes.
doc/user_guide.texi:
Document the new option
NEWS:
Announce the new option.
