Add ".pregen" or ".spf" to MR_GRADE_OPT variable.

".pregen" and ".spf" are settable on the command-line and should
therefore be included in MR_GRADE_OPT.

runtime/mercury_grade.h:
	As above.
Compile time evaluation of string.count_codepoints.

compiler/const_prop.m:
    Do compile time evaluation of count_codepoints where possible.

    Fix an old error in a comment: functions with two arguments are
    binary, not unary.
Disable very verbose messages from library grade detection by default.

compiler/mercury_compile.m;
	Make very verbose messages from library grade detection depend
	upon a compile-time trace flag.  Currently, such messages will
	appear before the usage message if the compiler is invoked
	without any arguments and that looks confusing.
Fix a problem with `--output-link-library-flags'.

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.
Add ".pregen" or ".spf" to MR_GRADE_OPT variable.

".pregen" and ".spf" are settable on the command-line and should
therefore be included in MR_GRADE_OPT.

runtime/mercury_grade.h:
	As above.
Fix a problem with `--output-link-library-flags'.

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.
Add support for specifying the "system" environment type.

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.
Fix a problem that broke the rotds on some platforms.

runtime/mercury_grade.h:
	MR_GRADE_OPT_PART_11 wasn't being defined if we were using boxed
	double-precision floats.
Merge branch 'version-13_05-branch'
Add more patterns to .gitignore files

A number of patterns and filenames where missing from .gitignore files,
especially in the tests/ directory.

.gitignore:
boehm_gc/.gitignore:
boehm_gc/libatomic_ops/pkgconfig/.gitignore:
runtime/.gitignore:
scripts/.gitignore:
tests/.gitignore:
tests/analysis/table/.gitignore:
tests/analysis/trail/.gitignore:
tests/benchmarks/.gitignore:
tests/debugger/.gitignore:
tests/invalid/.gitignore:
tests/mmc_make/.gitignore:
tests/mmc_make/lib/.gitignore:
    Add new patterns to .gitignore files.

    Remove some patterns that are implicit because they're in a parent
    directory's file.

tests/analysis/.gitignore:
    After removing superfluous patterns this file was empty.  I've deleted
    it.
Fix problems with building PDF documentation

The PDF documents were sometimes generated without their tables of contents.
This could happen if for some reason there was no .toc file but the .dvi
file still existed.  The Mmakefile would not run texi2dvi which would
normally produce a toc file if the .dvi file already existed, this caused
pdftex to fail to include the table of contents in the generated PDF file.

This was common as distclean deleted the .toc file but did not delete the
.dvi file, so this commonly happened when generating documentation from a
source distribution tarball as we do for the webpage.

This change causes distclean to also delete the .dvi files.

doc/Mmakefile:
    As above

    Also make library.dvi depend upon library-menu.texi_pp
    and library-chapters.texi_pp
Merge branch 'version-13_05-branch'
Update .gitignore files

doc/.gitignore:
    .gitignore several generated file extensions.

runtime/.gitignore:
    .gitignore the tags file.
Refactor clean Mmake targets in doc/

doc/Mmakefile:
    Refactor the clean targets in the doc/ directory.  Now it is very clear
    that the 'realclean' and 'distclean' targets do the same thing, and
    'distclean' is only removes a few additional things than 'clean' does.

    This will reduce the chance of problems similar to the one affecting the
    table of contents' in the PDF documents.
Add test cases for bug300

tests/valid/bug300.m:
tests/valid/Mmakefile:
    This simple test case can detect the bug in Java grades.

tests/valid/Mercury.options:
    Run the new test case with --optimize-constructor-last-call

tests/hard_coded/bug300.m:
tests/hard_coded/bug300.exp:
tests/hard_coded/Mmakefile:
    This more complicated test case can detect the bug in C grades.  However
    it requires specific CFLAGS, beyond LCMC, to do so.  The symptoms of the
    bug appear differently in this case.

tests/hard_coded/Mercury.options:
    Setup MCFLAGS so that the test case can detect the bug.
Fix bug300

The last call modulo construction (LCMC) transformation ignores from ground
term scopes, this is incorrect when the from ground term scope makes ground
one of the variables whose construction we're trying to move before a
recursive call.  This can occur when the from ground term scope occurs in a
non-recursive case (and possible alternative recursive cases).  This was
only affecting non-C grades because the C grades transform the from ground
term scopes into single unification before LCMC is performed.

We fix this bug by performing the LCMC transformation on a from ground term
(FGT) scope by treating the scope as a construction unification goal.  This
is correct because such a goal is always the last goal in the FGT scope.  We
only process scopes that bind one of the variables whose construction we're
trying to optimize.

compiler/lco.m:
    As above.

NEWS:
    Add news file entry.
Merge branch 'version-13_05-branch'
Fix some documentation in the configuration script.

configure.ac:
	Delete a reference to a non-existent README file.

	Fix the wording of a comment.
Fix and enable the mfilterjavac option

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.
Move pointer_equals/2 into the private_builtin module.

library/version_hash_table.m:
library/private_builtin.m:
    Move pointer_equals/2 as above.

    Rename pointer_equals to pointer_equal.

library/private_builtin.m:
    Adjust a comment to say that this module also contains predicates with
    normal definitions.  That is, they're built into the language but not
    built into the compiler.