They do not currently work in-situ because the launcher scripts we generate do
not set MONO_PATH appropriately. Use the new --mono-path-directory option to
remedy this.
compiler/COMP_FLAGS.in:
deep_profiler/DEEP_FLAGS.in:
grade_lib/GRADE_LIB_FLAGS.in:
mfilterjava/MFILTERJAVAC_FLAGS.in:
profiler/PROF_FLAGS.in:
slice/SLICE_FLAGS.in:
As above.
browser/MDB_FLAGS.in:
deep_profiler/DEEP_FLAGS.in:
grade_lib/GRADE_LIB_FLAGS.in:
library/LIB_FLAGS.in:
mdbcomp/MDBCOMP_FLAGS.in:
mfilterjavac/MFILTERJAVAC_FLAGS.in:
profiler/PROF_FLAGS.in:
slice/SLICE_FLAGS.in:
ssdb/SSDB_FLAGS.in:
Stop specifying --no-warn-inferred-erroneous as the default for
every module in these directories, most of which did not even need it
(the result of blind copying in the absence of STANDARD_MCFLAGS).
browser/Mercury.options:
library/Mercury.options:
Specify --no-warn-inferred-erroneous for the modules that
actually do need it.
STANDARD_MCFLAGS:
Put the mmc options that are common to either
- all of the dir/DIR_FLAGS.in files, or
- all but one of them,
into this new file.
(MFILTERJAVAC_FLAGS did not specify --warn-suspicious-foreign-code;
after this diff, it does.)
configure.ac:
Enable replacing @STANDARD_MCFLAGS@ with the new file's contents.
browser/MDB_FLAGS.in:
compiler/COMP_FLAGS.in:
deep_profiler/DEEP_FLAGS.in:
grade_lib/GRADE_LIB_FLAGS.in:
library/LIB_FLAGS.in:
mdbcomp/MDBCOMP_FLAGS.in:
mfilterjavac/MFILTERJAVAC_FLAGS.in:
profiler/PROF_FLAGS.in:
slice/SLICE_FLAGS.in:
ssdb/SSDB_FLAGS.in:
Include STANDARD_MCFLAGS instead of listing each option in it
individually, making future global changes to options easier.
Put .mh files into a Mercury/mhs subdirectory when --use-subdirs
or --use-grade-subdirs is used.
compiler/file_names.m:
Replace ext_cur_mh with ext_cur_ngs_max_cur_mh, in the new category
ext_cur_ngs_max_cur. The new category is similar to that for .mih
files, except that .mh files are never placed in grade-specific
subdirectories.
compiler/handle_options.m:
Add Mercury/mhs subdirs to list of C include directories
when --use-subdirs or --use-grade-subdirs is in effect.
compiler/write_deps_file.m:
Add $(mhs_subdir) prefix before %.mh patterns.
Create a Mercury/mhs -> .. symlink when installing.
This is required by mmc --make and mmake --use-subdirs.
Conform to the changes above.
compiler/export.m:
compiler/make.file_names.m:
compiler/make.program_target.m:
compiler/mercury_compile_llds_back_end.m:
compiler/mlds_to_c_file.m:
Conform to the changes above.
scripts/Mmake.vars.in:
Define the variable mhs_subdir.
scripts/Mmake.rules:
Add -I option to find .mh files when --use-subdirs is used.
browser/.mgnuc_copts:
browser/MDB_FLAGS.in:
compiler/.mgnuc_copts:
compiler/COMP_FLAGS.in:
deep_profiler/.mgnuc_copts:
deep_profiler/DEEP_FLAGS.in:
extras/EXTRAS_FLAGS.in:
grade_lib/.mgnuc_copts:
grade_lib/GRADE_LIB_FLAGS.in:
library/.mgnuc_copts:
mdbcomp/.mgnuc_copts:
mdbcomp/MDBCOMP_FLAGS.in:
mfilterjavac/.mgnuc_copts:
mfilterjavac/MFILTERJAVAC_FLAGS.in:
profiler/.mgnuc_copts:
profiler/PROF_FLAGS.in:
slice/.mgnuc_copts:
slice/SLICE_FLAGS.in:
ssdb/.mgnuc_copts:
ssdb/SSDB_FLAGS.in:
tests/.mgnuc_copts.ws:
tests/WS_FLAGS.ws:
trace/.mgnuc_copts:
tools/lmc.in:
Add -I options to find .mh files when the workspace is built
with mmake --use-subdirs.
samples/c_interface/standalone_c/Makefile:
Add option to let the C compiler find the .mh file.
NEWS.md:
Announce change.
Delete trailing whitespace.
configure.ac:
Require the installed compiler to support both the option,
and the Mmake rules that invoke it.
compiler/Mmakefile:
library/Mmakefile:
mdbcomp/Mmakefile:
mfilterjavac/Mmakefile:
ssdb/Mmakefile:
Get the mmake depend to depend on prog.depend_ints, not prog.depend,
Give the prog.depend_ints targets themselves the same prerequisites
as the existing prog.depend targets.
In mfilterjavac/Mmakefile, fix what looks like an old problem
by making the depend target a prerequisite of the check and ints targets.
... instead of building a bunch of .c files.
Our tradition of adding an "s" at the end of a suffix to mean "all of the
files with the original suffix" had a problem when we added C# as a target
language. Until then, just as "os" stood for ".o files" when it occurred
as either a mmake target, mmc --make target, or mmake variable name component.
"cs" likewise stood for ".c files", but was now also needed to mean ".cs file".
We coped by keeping "cs" meaning ".c files", and adding "csharp" as a target
name synonym to mean ".cs file".
This diff keeps that synonym, but it changes
- the name needed to refer to ".c files" from "cs" to "all_cs"
- the name needed to refer to ".o files" from "os" to "all_os"
- the name needed to refer to ".pic_o files" from "pic_os" to "all_pic_os"
- the name needed to refer to ".cs files" from "css" to "all_css"
- the name needed to refer to ".java files" from "javas" to "all_javas"
- the name needed to refer to ".opt files" from "opts" to "all_opts"
- the name needed to refer to ".trans_opt files"
from "trans_opts" to "all_trans_opts"
It would be nice if we could apply this same change to all other similar
target names and mmake variable name suffixes, such as "ints" and "int3s",
but some of those names are already in use to mean semantically different
things. All of the names above that used to have the form "<ext>s" and
now have the form "all_<ext>s" stood for all the files with extension
".<ext>" that are prerequisites for building a linked target, i.e.
an executable or a library. But the mmake variable name suffixes
".all_mihs", ".all_mhs" and ".all_int0s" each stand for something subtly
different: the names of files that *may or may not exist", but which,
if they do exist, should be deleted by a clean or realclean target.
To make this breaking change easier to handle by users, this diff does
not simply redefine the meaning of ".all_int0s". (It does change the meaning
of the "cs" target, but the fact this will happen at some time has been
announced ages ago.) Instead, it defines three new mmake var suffixes,
".mihs_to_clean", ".mhs_to_clean" and ".int0s_to_clean", which are
synonyms for ".all_mihs", ".all_mhs" and ".all_int0s" respectively,
and announces that ".all_mihs", ".all_mhs" and ".all_int0s" are being
deprecated, and will have the above change of semantics applied to them
in the future.
NEWS.md:
Announce the breaking change.
compiler/make.top_level.m:
Stop treating the target "cs" as meaning "build all the .c files
for this program".
The code of classify_target_2 has long been semidet, but only in a way
that was not apparent to the compiler. Change the code to allow the
compiler to see its semidet nature while keeping the algorithm the same,
except for the change in the paragraph above.
This includes keeping e.g. "ints" as meaning "build all the .int/.int2
files needed by this program".
compiler/write_deps_file.m:
Stop generating mmake variables with suffixes ".cs", ".os", ".pic_os",
".javas" and ".css". The mmake variables with suffixes ".all_cs",
".all_os", ".all_pic_os", ".all_javas" and ".all_css" already existed.
All had the same value as the mmake variable without the "all",
with one exception: ".cs". However, in this case, the old (and still
current) value of ".all_cs" is what the value of ".cs" *should* have been.
Simplify some code.
The following changes in compiler/*.m are only cosmetic, but they helped me
rule out possible sources of problems with incomplete versions of this diff.
compiler/file_names.m:
Add a version of a fact_table_file_name_return_dirs which does not
return directories, since most of its callers don't need that info.
compiler/make.program_target.m:
Clarify code by making variable names more descriptive,
compiler/make.file_names.m:
compiler/make.module_target.m:
Conform to the changes above,
browser/Mmakefile:
compiler/Mmakefile:
deep_profiler/Mmakefile:
grade_lib/Mmakefile:
library/Mmakefile:
mdbcomp/Mmakefile:
mfilterjavac/Mmakefile:
profiler/Mmakefile:
slice/Mmakefile:
ssdb/Mmakefile:
Rename os to all_os, cs to all_cs, css to all_css, javas to all_javas,
and opts to all_opts. (There were no occurrences of trans_opts to rename.)
Replace [s as sh command names in actions.
scripts/Mmake.vars.in:
Specify the names of mmake variables holding the names of sets of files
with a given extension directly, since for some of them, adding an "s"
at the end of the name of the extension does not generate the name
of the corresponding mmake variable anymore.
scripts/Mmake.rules:
Use the directly specified mmake variable names from Mmake.vars.in
in the rule for installing lbraries. Temporarily add some debugging
output to make suree that the updated nested mmake variable references
work as intended.
tools/bootcheck:
Specify the names of mmake targets for making all the files in a program
with a given extension directly, since adding an "s" at the end of the
name of the extension does not generate the name of the corresponding
mmake target anymore.
Print timestamps around the action of checking namespace cleanliness,
to allow the time taken by that action to be measured. (I kept track
of bootchecks as they happened while working on this diff, and found
this time to be nontrivial.)
configure.ac:
Require the installed compiler to support --allow-insts-as-modes
(and therefore its negation).
*/*_FLAGS.in:
Add -no-allow-ho-insts-as-modes as a default option.
compiler/bytecode_data.m:
compiler/deforest.m:
compiler/inst_graph.m:
compiler/introduce_parallelism.m:
compiler/mode_constraint_robdd.m:
compiler/mode_constraints.m:
compiler/mode_robdd.equiv_vars.m:
compiler/mode_robdd.implications.m:
compiler/mode_robdd.tfeirn.m:
compiler/parse_util.m:
compiler/recompilation.version.m:
compiler/set_of_var.m:
compiler/term_constr_fixpoint.m:
deep_profiler/array_util.m:
deep_profiler/autopar_find_best_par.m:
deep_profiler/dump.m:
deep_profiler/interface.m:
deep_profiler/program_representation_utils.m:
mdbcomp/program_representation.m:
Add in() wrappers around higher order insts used as modes.
Use simply "in" as the mode of functions with the default mode
and determinism.
Fix a few style issues.
as the default for the Mercury system.
configure.ac:
Require the installed compiler to support this option.
browser/MDB_FLAGS.in:
compiler/COMP_FLAGS.in:
deep_profiler/DEEP_FLAGS.in:
grade_lib/GRADE_LIB_FLAGS.in:
library/LIB_FLAGS.in:
mdbcomp/MDBCOMP_FLAGS.in:
mfilterjavac/MFILTERJAVAC_FLAGS.in:
profiler/PROF_FLAGS.in:
slice/SLICE_FLAGS.in:
ssdb/SSDB_FLAGS.in:
Specify this option as the default in their directories.
The main objective of this change is to get bootchecks in the csharp
and java grades to actually build the slice, profiler, deep_profiler
and mfilterjavac directories, which (due to the bug this diff fixes)
they weren't doing before.
However, since one side effect of this change is to eliminate
one source of annoying warnings from mmake about references to undefined
variables, a subsidiary objective is to eliminate other sources of such
warnings as well, which mostly come from the rules for making tags files.
browser/Mmakefile:
deep_profiler/Mmakefile:
library/Mmakefile:
mdbcomp/Mmakefile:
profiler/Mmakefile:
slice/Mmakefile:
ssdb/Mmakefile:
When creating stage 3, the bootcheck builds, in each directory,
only the files that it wants to compare against their stage 2 versions.
This means that it wants to build all the .c, .cs or .java files,
which it does via the cs, css and javas mmake targets.
The correct definitions of the rules of these targets depends on
whether mmc --make is being used or not, so we need at least two
sets of definitions: one for mmc --make, and for no mmc --make,
and conditionally selecting the appropriate one. The latter definition
has the problem that it refers to mmake variables that are intended
to be defined in .dv files created by mmc --generate-dependencies,
but until that has been run, those mmake variables are undefined.
Until now, the only directories that had both the mmc --make
and the no mmc --make definitions were the ones needed to build
the compiler. Bootchecks in the csharp and java grades, which
always use --make make, got errors when they tried to build
the directories that bootcheck builds after the compiler:
the slice, profiler, deep_prof and mfilterjavac directories.
This diff ensures that all directories we build in bootcheck
get all both versions of the os, cs, css, and javas targets.
In fact, they get two subversions of the no mmc --make version:
one for use in the presence of .dv files, and one for use in their
absence. The latter just builds the .dv files and invokes mmake
again. This avoids one source of warnings about undefined mmake
variables.
To avoid another source, make the rules for tags files and their
proxies depends on *.m instead of mmake variables such as $(mcov.ms),
since this makes sense even before making dependencies. The only price
is that any untracked Mercury source files in the directory have to
either be given some other suffix, or moved somewhere else.
Where relevant, make the mtags invocation prefer the master versions
of files that are copied from the mdbcomp directory to other directories,
since this is the only writeable version.
Make the os and cs rules consistently NOT build the _init.[co] files.
The way we use those files in bootcheck, we never need them;
when we need them, the right target to give is the executable anyway.
In the slice directory, don't put mcov between mtc_union and mtc_diff.
Eliminate unnecessary duplication, e.g. of sources in rules.
Eliminate double negatives in conditionals.
Fix formatting.
Mmake.common.in:
bindist/Mmakefile:
bytecode/Mmakefile:
compiler/Mmakefile:
doc/Mmakefile:
grade_lib/Mmakefile:
robdd/Mmakefile:
samples/Mmakefile:
scripts/Mmakefile:
tools/Mmakefile:
trace/Mmakefile:
util/Mmakefile:
Add "ft=make" to vim modelines. This is redundant for the files whose
names is Mmakefile, but it is needed for Mmake.common.
library/LIB_FLAGS.in:
mfilterjavac/MFILTERJAVAC_FLAGS.in:
profiler/PROF_FLAGS.in:
slice/SLICE_FLAGS.in:
ssdb/SSDB_FLAGS.in:
Specify --warn-inconsistent-pred-order-clauses as a default flag
in these directories as well.
library/string.m:
Reorder code to make this module compile cleanly with
--warn-inconsistent-pred-order-clauses.
Don't export base_string_to_int_underscore to lexer.m, since
lexer.m does not use it anymore, and neither does anything else.
(The export was not publicly documented.)
library/benchmarking.m:
library/bitmap.m:
library/builtin.m:
library/map.m:
library/profiling_builtin.m:
library/rbtree.m:
library/table_builtin.m:
library/uint.m:
profiler/globals.m:
profiler/options.m:
profiler/prof_info.m:
slice/mdice.m:
slice/mslice.m:
slice/mtc_diff.m:
slice/mtc_union.m:
ssdb/ssdb.m:
Reorder code to make these modules compile cleanly with
--warn-inconsistent-pred-order-clauses.
library/Mercury.options:
Specify --no-warn-inconsistent-pred-order-clauses for the modules
that would still get warnings without this option.
tools/bootcheck:
Build the deep_profiler and mfilterjavac directories in stage 2.
Build the slice, profiler, deep_profiler and mfilterjavac directories
in stage 3. (We already used to build slice and profiler in stage 2.)
Compare target language files in the stage 2 and stage 3 versions
of the slice, profiler, deep_profiler and mfilterjavac directories,
to make bootcheck a tougher test. This requires copying these directories
to stage 3, instead of just linking them.
Don't make dependencies in a directory if we had already done them
earlier.
mfilterjavac/Mmakefile:
Add targets for building C# and Java files.
slice/Mmakefile:
Include the modules of the mcov and mtc_diff programs in the
existing targets for building C, C# and Java files.
deep_profiler/Mmakefile:
profiler/Mmakefile:
These makefiles already had targets for building C# and Java files.
Fix grammar and/or indentation.
compiler/Mmakefile:
Fix grammar and/or indentation.
configure.ac:
Require the installed compiler to have the recent bug fix to
contiguity warnings, since without that bug fix, we get warnings
for code that is actually perfectly ok.
browser/MDB_FLAGS.in:
compiler/COMP_FLAGS.in:
deep_profiler/DEEP_FLAGS.in:
library/LIB_FLAGS.in:
mdbcomp/MDBCOMP_FLAGS.in:
mfilterjavac/MFILTERJAVAC_FLAGS.in:
profiler/PROF_FLAGS.in:
slice/SLICE_FLAGS.in:
ssdb/SSDB_FLAGS.in:
Specify both --warn-non-contiguous-clauses and
--warn-non-contiguous-foreign-procs as the default in each directory.
library/Mercury.options:
Disable the warnings for exception.m and io.m, which are have not
been cleaned up yet wrt these warnings.
configure.ac:
Require that the installed compiler support this option (which I added
about two weeks ago).
browser/MDB_FLAGS.in:
compiler/COMP_FLAGS.in:
deep_profiler/DEEP_FLAGS.in:
library/LIB_FLAGS.in:
mdbcomp/MDBCOMP_FLAGS.in:
mfilterjavac/MFILTERJAVAC_FLAGS.in:
profiler/PROF_FLAGS.in:
slice/SLICE_FLAGS.in:
ssdb/SSDB_FLAGS.in:
Specify this option by default for every directory that contains
Mercury code.
browser/MDB_FLAGS.in:
compiler/COMP_FLAGS.in:
deep_profiler/DEEP_FLAGS.in:
library/LIB_FLAGS.in:
mdbcomp/MDBCOMP_FLAGS.in:
mfilterjavac/MFILTERJAVAC_FLAGS.in:
profiler/PROF_FLAGS.in:
slice/SLICE_FLAGS.in:
ssdb/SSDB_FLAGS.in:
Add --warn-unused-imports to the list of default compiler flags
for each directory.
compiler/ml_tailcall.m:
library/io.m:
Delete some unused imports.
Don't accidently strip the ".exe" extension from the deep profiler executables
on Windows when installing them. (Deep profiling doesn't really work on
Windows, which is why this hasn't been noticed until now.)
compiler/Mmakefile:
mfilterjavac/Mmakefile:
profiler/Mmakefile:
slice/Mmakefile:
Add an uninstall target in these directories.
Delete a stray reference to the IL backend.
deep_profiler/Mmakefile:
Fix the issue mentioned above w.r.t the ".exe" extension.
We install mdprof_cgi in (potentially) two locations, make
sure we (attempt to) uninstall them both.
Update the uninstall target to handle the other executables in
this directory.
doc/Mmakefile:
Make the uninstall target remove the manual pages.
Mmakefile:
Invoke uninstall targets in directories where we previously didn't.
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.
Make it possible to run the installed Java version of the compiler by
installing versions of the wrapper scripts for 'mercury_compile' and
'mfilterjavac' that have the CLASSPATH set to point to the installed versions
of the standard library Java archives.
The wrapper script generated in the compiler directory is not suitable for this
because as generated it sets the CLASSPATH relative to the compiler directory,
not the installation directory. Modifying that file is not a good idea since
that will mean that then the compiler cannot be executed in situ. Instead we
provide a handwritten version of the wrapper script in the scripts directory
that is installed in place of the generated one. Ditto for mfilterjavac.
While this does create a small maintenance problem, I think that any other
approach, for example, modifying the generation of wrapper scripts to account
for this, is going to be a larger maintenance problem.
TODO:
- handle batch file launchers for Windows.
- handle other executables in the Mercury system (although most of these
are not so important in this context).
compiler/Mmakefile:
mfilterjavac/Mmakefile:
Do not install generated wrapper scripts from these directories in the Java
grade.
scripts/mercury_compile.sh-java:
scripts/mfilterjavac.sh-java:
Java wrappers scripts for the installed versions of the compiler
and mfilterjavac.
scripts/Mmakefile:
In the Java grade install the wrapper scripts for the compiler and
mfilterjavac from this directory.
If the compiler and (most of) the other tools are built in the Java grade then
have the install target also install the Java archives for the executables.
compiler/Mmakefile:
deep_profiler/Mmakefile:
mfilterjavac/Mmakefile:
profiler/Mmakefile:
slice/Mmakefile:
As above. (The ones for the deep profiling tools are are probably
a bit useless in practice, but the others should all work.)
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.
*/*_FLAGS.in:
Specify that by default, the compiler should generate warnings
for unknown format strings and bad known format strings.
*/Mercury.options:
Override this default setting for a few modules that have legitimate
reasons for calling e.g. string.format with unknown format strings.
compiler/fact_table.m:
deep_profiler/html_format.m:
Minor changes to avoid calling string.format with unknown format strings.
This file-specific setting will override a default setting of expandtabs
in $HOME/.vimrc.
*/Makefile:
*/Mmakefile:
As above.
tests/hard_coded/.gitignore:
Don't ignore the purity subdir. This ignore must have been left over
from when purity.m was a test in hard_coded, not hard_coded/purity,
and it ignored an executable, not a directory.
Fix some problems that were preventing the system from compiling properly with
MSVC.
(1) Visual Studio 2013 no longer includes the files NtWin32.Mak and Win32.Mak
which are required for building the Boehm GC with MSVC. (This appears to be an
issue with upstream Boehm as well.) The workaround here is to reference the
copies of this files included with the Windows 7 SDK. (This appears to be the
official Microsoft workaround for dealing with this problem for now.)
(2) Disable support for `--c-debug' when using MSVC. Using this option causes
MSVC to emit .pdb (Program Data Base), that contain the symbol information for
an object files. This causes a variety of problems:
(i) parallel builds are contending for the vc*.pdb file shared by all the
object files in a directory causing compilation to abort. (Compiling with
the -FS option is another solution to this -- it causes the compiler to
serialize access to the .pdb file -- but at the cost of slowing down
compilation.)
(ii) .pdb files are not cleaned up by realclean; compilation will abort
if a pdb file generated by a different version of MSVC is encountered.
(iii) we don't install the .pdb files alongside the libraries anyway.
This can be a source of linker warnings. (And shutting up the Microsoft
linker seems to be very difficult indeed ...)
(iv) compiling with -Zi (apparently) inhibits some C compiler optimizations.
Compiling with the older -Z7 (MSVC 7 style debugging info) option is another
alternative. Using that option causes MSVC to include symbol information in
the object files, instead of in a separate file.
For now (i.e. the 14.01 release), disabling `--c-debug' for MSVC is the
simplest way of addressing the above issues.
README.MS-VisualC:
Describe the problem with NtWin32.Mak and Visual Studio 2013 and
provide two possible workarounds.
Mention that `--c-debug' is not currently supported with MSVC and how
to re-enable it.
Simplify some of the instructions for setting up the build environment.
configure.ac:
scripts/mgnuc.in:
Disable `--c-debug' with MSVC.
scripts/prepare_install_dir.in:
Copy all makefile fragments for nmake into the boehm_gc directory for
the library grade installation. (This is in case the user copies
NtWin32.Mak etc into the boehm_gc directory as per the second of
the workarounds in README.MS-VisualC.)
slice/Mmakefile:
compiler/Mmakefile:
deep_profiler/Mmakefile:
mfilterjavac/Mmakefile:
profiler/Mmakefile:
slice/Mmakefile:
Clean up any .pdb files. Note that one is generated for each
executable (regardless of whether -Zi is given to cl or not).
In addition, if -Zi is given to cl, there will be file named
vc<version>.pdb generated (where <version> is the version of MSVC being
used.)
Julien reported a bootstrap problem when mfilterjavac was enabled and a Java
grade was being installed but the installed compiler did not have an
mfilterjavac program. When installing a Java grade the mfilterjavac program
in the workspace was not in the PATH. This change ensures that mfilterjavac
is in the path and enables it's use in the compiler.
compiler/options.m:
Enable the mfilterjavac option.
Mmakefile:
Set the PATH in SUBDIR_MAKE and SUBSUBDIR_MAKE correctly so that the
compiler can find mfilterjavac.
tools/bootcheck:
Run 'mmake depend' in stage2/mfilterjavac in the same way that we do for
the other directories.
mfilterjavac/.gitignore
Ignore tags related files in this directory.
Library grade detection causes the library installation for the csharp grade
(and probably any grades that use mmc --make) to fail. (There is likely
a better solution than this, e.g. making --no-mercury-stdlib-dir imply
--no-detect-libgrades, but the handling of command line options in this
part of the compiler is pretty convoluted, so I will look into that
separately.)
browser/MDB_FLAGS.in:
compiler/COMP_FLAGS.in:
deep_profiler/DEEP_FLAGS.in:
library/LIB_FLAGS.in:
mdbcomp/MDBCOMP_FLAGS.in:
mfilterjavac/MFILTERJAVAC_FLAGS.in:
profiler/PROF_FLAGS.in:
slice/SLICE_FLAGS.in:
ssdb/SSDB_FLAGS.in:
As above.
Add the mfilterjavac utility to filter javac's output and re-write the error
locations.
mfilterjavac/mfilterjavac.m:
As above
Mmakefile:
configure.ac:
mfilterjavac/Mmakefile
mfilterjavac/MFILTERJAVAC_FLAGS.in:
mfilterjavac/.mgnuc_opts:
mfilterjavac/.mgnuc_copts:
Adjust the build system to support the new mfilterjavac directory.
