tests/hard_coded/uint_bitwise.m:
The C foreign procs in this module require the definition of
ML_BITS_PER_UINT; add the required foreign_import_module pragma.
(This currently "works" in many other grades because uint.mh gets
implicitly imported.)
compiler/const_prop.m:
Extend this module to support compile time evaluation of uint operations.
compiler/uint_emu.m:
A new module that emulates `uint' operations for the bits-per-uint in
a manner similar to the int_emu module.
compiler/libs.m:
Include the new module.
tests/hard_coded/constant_prop_1.{m,exp}:
tests/hard_coded/constant_prop_2.{m,exp}:
Test compile time evaluation of uint operations.
Update coding style in these tests.
tests/hard_coded/Mmakefile:
Conform to the above changes. (XXX the existing check
for the Java grade doesn't actually work.)
Delete left over IL and GCC backend stuff.
library/uint.m:
Add (//)/2, (/)/2 and rem/2 for uints.
Add mod/2 and div/2 as synonyms for the above.
tests/hard_coded/uint_arith.m
Enable the division tests.
tests/hard_coded/uint_bitwise.exp*:
Update the expected outputs.
library/uint.m:
Add checked left and right shift operations on uints.
tests/hard_coded/Mmakefile:
tests/hard_coded/uint_bitwise.m:
Test bitwise operators on uints.
tests/hard_coded/uint_bitwise.exp:
Expected output for 64-bit machines.
tests/hard_coded/uint_bitwise.exp2:
Expected output for 32-bit machines (as well as the
C# and Java grades).
library/bag.m:
Add predicates and a function for efficiently inserting multiple copies of
an item into a bag.
NEWS:
Announce the above additions.
tests/hard_coded/bag_various.{m,exp}:
Extend this test to cover the above.
tests/hard_coded/Mmakefile:
tests/hard_coded/uint_arith.m:
tests/hard_coded/uint_arith.exp*:
As above. (The .exp file is for 64-bit machines; the .exp2 for
32-bit.)
Extend the lexer to recognise uint literals, optional signedness suffixes on
ints and the literals for all of the proposed fixed size integer types.
Fix XXX UINTs in the library and compiler.
library/lexer.m:
Uncomment the other alternatives in the integer_size/0 type.
Handle signedness and size suffixes in integer literals.
library/parser.m
library/term.m:
Conform to the above changes.
library/stream.string_writer.m:
Fix an XXX UINT: make write handle uints properly.
library/term_io.m:
Fix an XXX UINT: output integer signedness and size suffixes for
integers when appropriate.
compiler/superhomogeneous.m:
Print an error message if we encounter a fixed size integer literal
as the rest of the compiler does not yet support them.
compiler/hlds_out_util.m:
compiler/parse_tree_out_info.m:
Output the 'u' suffix on uint values.
test/hard_coded/lexer_zero.{m,inp,exp*}:
Extend this test to cover zeros of varying signedness and size.
Prefix each line of the output with the input line number of the
token -- this makes it easier to relate the output back to the
input.
tests/hard_coded/Mmakefile:
Add the new test case.
tests/hard_coded/lexer_ints.{m,inp,exp}:
Test the lexer on non-zero integer literals.
library/lexer.m:
Merge the 'integer' and 'big_integer' tokens and extend them to include
signedness and size information. This conforms to recent changes to
the rest of the system and is another step towards supporting additional
types of integer literal.
library/parser.m:
mdbcomp/trace_counts.m:
Conform to the above change.
tests/hard_coded/impl_def_lex.exp:
tests/hard_coded/impl_def_lex_string.exp:
tests/hard_coded/lexer_bigint.exp:
tests/hard_coded/lexer_zero.exp*:
tests/hard_coded/parse_number_from_string.exp*:
Update these expected outputs.
In preparation for supporting uint literals and literals for the fixed size
integer types, generalise the representation of integers in the term module, so
that for every integer literal we record its base, value (as an arbitrary
precision integer), signedness and size (the latter two based on the literal's
suffix or lack thereof).
Have the lexer attach information about the integer base to machine sized ints;
we already did this for the 'big_integer' alternative but not the normal one.
In conjunction with the first change, this fixes a problem where the compiler
was accepting non-decimal integers in like arity specifications. (The
resulting error messages could be improved, but that's a separate change.)
Support uints in more places; mark other places which require further work with
XXX UINT.
library/term.m:
Generalise the representation of integer terms so that we can store
the base, signedness and size of a integer along with its value.
In the new design the value is always stored as an arbitrary precision
integer so we no longer require the big_integer/2 alternative; delete it.
Add some utility predicates that make it easier to work with integer terms.
library/term_conversion.m:
library/term_io.m:
Conform to the above changes,
Add missing handling for uints in some spots; add XXX UINT comments
in others -- these will be addressed later.
library/lexer.m:
Record the base of word sized integer literals.
library/parser.m:
compiler/analysis_file.m:
compiler/fact_table.m:
compiler/get_dependencies.m:
compiler/hlds_out_goal.m:
compiler/hlds_out_util.m:
compiler/intermod.m:
compiler/make.module_dep_file.m:
compiler/parse_class.m:
compiler/parse_inst_mode_name.m:
compiler/parse_item.m:
compiler/parse_pragma.m:
compiler/parse_sym_name.m:
compiler/parse_tree_out_term.m:
compiler/parse_tree_to_term.m:
compiler/parse_type_defn.m:
compiler/parse_util.m:
compiler/prog_ctgc.m:
compiler/prog_util.m:
compiler/recompilation.check.m:
compiler/recompilation.version.m:
compiler/superhomogeneous.m:
mdbcomp/trace_counts.m:
samples/calculator2.m:
extras/moose/moose.m:
Conform to the above changes.
tests/hard_coded/impl_def_lex.exp:
tests/hard_coded/impl_def_lex_string.exp:
tests/hard_coded/lexer_bigint.exp*:
tests/hard_coded/lexer_zero.exp*:
tests/hard_coded/parse_number_from_string.exp*:
tests/hard_coded/term_to_unit_test.exp:
Update these expected outputs.
library/integer.m:
As above -- I have upcoming changes that require this.
(There's a bunch places marked XXX UINT that will need
to revisited once more uint support is available.)
tests/Mmakefile:
tests/hard_coded/integer_uint_conv.{m,exp,exp2}:
Add test for the conversions.
Lets say an SCC contains n procedures, P1 through Pn. The SCC is *linearly
tail recursive* if the set of tail recursive calls in the SCC is {P1 -> P2,
P2 -> P3, ... Pn-1 -> Pn, Pn -> P1}, i.e. each procedure calls the next one
and the last one calls the first. For each Pi that is called from above
the SCC, the new optimization inlines the callee at every tail recursive
call site except the one that calls Pi itself. For example, if Pi is P1,
it would inline the tail call to P2, the tail call to P3 inside P2,
the tail call to P4 inside P3, and so on. Since the only tail recursive
call left in Pi is to Pi, this scheme transforms mutual tail recursion,
which the MLDS backend cannot (yet) implement, into self tail recursion,
which it *can* implement.
We only perform the transformation if each procedure in the SCC
contains *exactly one* tail recursive call. This is because each extra
tail recursive call may *double* the size of the resulting code.
Any recursive calls that are not *tail* recursive are left alone.
compiler/options.m:
doc/user_guide.texi:
Add a new option, --inline-linear-tail-rec-sccs, that calls for the
new transformation.
NEWS:
Announce the new option.
compiler/mercury_compile_middle_passes.m:
Call inlining if the new option is set.
compiler/inlining.m:
If the new option is given, implement the transformation described
at the top.
Fix several variable and predicate names that misleadingly implied
that a predicate *has* been inlined when it has only been decided
that it is *worth* inlining, with the actual inlining taking place later.
Pass the needed_map inside the inline_params.
Rename the top predicate to fit the naming scheme used in the rest
of the module.
compiler/hlds_goal.m:
Add a goal feature that designates the call that it decorates as being
either a self or a mutual tail recursive call.
Rename the existing goal features that apply only to self tail recursive
calls to make clear that fact.
compiler/mark_tail_calls.m:
Generalize the code to look either for
- just self tail recursive calls, as at the moment, as needed by both
the LLDS and the MLDS code generator (for different purposes), or for
- both self and mutual tail recursive calls, as needed by the new
kind of inlining.
Give the top level predicates names that indicate their overall purpose.
Change the representation of the at_tail type to separate out the
flag that says whether we have or haven't seen a recursive call
in the backward traversal so far. This yields cleaner code
in several places.
Store the list of generated error_specs, and the flag that says whether
the traversal has found any recursive call, in the mark_tail_calls_info
structure, instead of returning them as separate output arguments.
This is better, since *most* places don't add error_specs or set the flag.
compiler/dependency_graph.m:
Explicitly gather the list of edges in the graph we are building,
and record that list. Inlining now needs this, because it needs to know
not just that e.g. two procedures p and q in an SCC call each other,
also *from how many call sites". The dependency graph does not contain
that information, but the list of edges from which it is built does.
compiler/hlds_dependency_graph.m:
For most purposes, we want to add an edge from p to q if
- p calls q in a tail call,
- p calls q in a non-tail call, or
- p *refers* to q without calling it, e.g. by constructing a closure
whose procedure is q.
However, when constructing the *tail* SCC within a conventional SCC,
we want to add an edge from p to q only in the first situation.
Add an option that controls whether we add an edge just in the first
situation or all three.
compiler/ml_tailcall.m:
ZZZ
compiler/call_gen.m:
compiler/deep_profiling.m:
compiler/deforest.m:
compiler/mercury_compile_llds_back_end.m:
compiler/saved_vars.m:
compiler/term_constr_main.m:
Conform to the changes above.
tests/hard_coded/tail_rec_scc.{m,exp}:
A new test case for the new option.
tests/hard_coded/Mmakefile:
tests/hard_coded/Mercury.options:
Enable the new test case.
The lexer was not allowing underscores between leading zeros in decimal integer
literals and float literals (e.g. 0_0 or 0_0.0).
library/lexer.m:
Allow underscores in the above cases.
tests/hard_coded/parse_number_from_io.{m,exp,exp2,exp3}:
tests/hard_coded/parse_number_from_string.{m,exp,exp2,exp3}:
Extend these tests to cover the above cases.
tests/invalid/invalid_binary_literal.err_exp:
tests/invalid/invalid_octal_literal.err_exp:
tests/invalid/invalid_hex_literal.err_exp:
Conform to the above change.
Standardize terminology in error messages about ill-formed numeric literals.
doc/reference_manual.texi:
Document underscores in numeric literals.
Add a TODO comment about a future piece of work.
NEWS:
Announce the addition of support for underscores in numeric literals.
library/lexer.m:
Use the term "literal" instead of "constant" or "token" when
referring to numeric literals in error messages.
s/hex/hexadecimal/ in those same error messages.
tests/hard_coded/parse_number_from_string.exp*:
tests/invalid/invalid_{binary,decimal,hex,octal}_literal.err_exp:
Conform to the above change in error messages from the lexer.
library/lexer.m:
Add a missing predicate.
tests/hard_coded/parse_number_from_io.exp[23]:
tests/hard_coded/parse_number_from_string.exp[23]:
Additional expected outputs for the Java and C# backends.
Allow the optional use of underscores in numeric literals for the purpose of
improving their readability (e.g. by grouping digits etc). We allow any number
of underscores between digits and also between the radix prefix (if present) and
the initial digit. (When integer type suffixes are supported we will also
allow them to be preceded by any number of underscores.) The following are
*not* allowed:
1. Leading underscores.
2. Trailing underscores.
3. Underscores inside the components of a radix prefix (e.g.
0_xffff or 0__b101010.)
4. Underscores immediately adjacent to the decimal point in a float
literal (e.g. 123_._123.)
5. Underscores immediately adjacent to the exponent ('e' or 'E) in
a float literal (e.g. 123_e12 or 123E_12.)
6. Underscores immediately adjacent to the optional sign of an exponent
in a float literal (e.g. 123_+e12 or 123-_E12.)
7. Underscores between the optional sign of an exponent and the exponent
indicator (e.g. 123+_e12.)
library/lexer.m:
Modify the scanner to account of underscores in numeric literals according
to the scheme above.
library/string.m:
library/integer.m:
Export undocumented functions for converting strings containing underscores
into ints or integers respectively.
tests/hard_coded/parse_number_from_io.{m,exp}:
Test parsing of valid numeric literals from file streams.
tests/hard_coed/parse_number_from_string.{m,exp}:
Test parsing of valid and invalid numeric literal from string.
tests/invalid/invalid_binary_literal.{m,err_exp}:
tests/invalid/invalid_decimal_literal.{m,err_exp}:
tests/invalid/invalid_octal_literal.{m,err_exp}:
tests/invalid/invalid_hex_literal.{m,err_exp}:
tests/invalid/invalid_float_literal.{m,err_exp}:
Test parsing of invalid numeric literals from file streams.
tests/hard_coded/parse_number_from_{io,string}.m:
tests/hard_coded/parse_number_from_{io,string}.exp:
Test parsing of valid numeric literals.
tests/hard_coded/Mmakefile:
tests/invalid/Mmakefile:
Add the new test cases.
tests/hard_coded/fact_table_test_{1,2}.{m,exp}:
Add these two test cases.
tests/hard_coded/fact_table_test_1_table_a:
tests/hard_coded/fact_table_test_1_table_b:
tests/hard_coded/fact_table_test_1_table_c:
tests/hard_coded/fact_table_test_2_table_a:
The fact table files of the new test cases.
tests/hard_coded/Mmakefile:
Enable the new test cases.
Begin implementing library support for uints.
Update the compiler to use the uint type.
library/uint.m:
Begin filling this module in.
library/private_builtin.m:
Use the proper argument type for builtin_{unify,compare}_uint
and provide actual implementations for them.
library/table_builtin.m:
Add tabling builtins for uints.
library/string.m:
Add a function to convert a uint to a decimal string.
(XXX NYI for Erlang).
library/io.m:
Add write_uint/[45].
Add the stream instance for uints and text output streams.
library/stream.string_writer.m:
Add put_uint/4.
Support uints in string_writer.write etc.
library/pprint.m:
Make uint an instance of the doc/1 type class.
library/pretty_printer.m:
Add a default formatter for uints.
library/int.m:
Unrelated change: fix formatting.
compiler/builtin_ops.m:
compiler/elds.m:
compiler/elds_to_erlang.m:
compiler/hlds_data.m:
compiler/llds.m:
compiler/llds_out_data.m:
compiler/mercury_to_mercury.m:
compiler/ml_lookup_switch.m:
compiler/mlds.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/opt_debug.m
compiler/parse_tree_out.m:
compiler/parse_tree_out_info.m:
compiler/prog_data.m:
compiler/prog_out.m:
compiler/prog_rep.m:
compiler/hlds_out_util.m:
Use the uint type in places where we should.
compiler/mlds_to_java.m:
Fix a bug that causes us to generate badly typed Java.
For div and mod we need to cast the entire expression to
an int, not just the first operand.
compiler/c_util.m:
compiler/mlds_to_cs.m:
Add predicates for outputting unsigned integers in C and C#.
tests/hard_coded/test_pretty_printer_defaults.exp:
Conform to the above change to the pretty_printer module.
After upgrading the collector this test started to fail, but probably not
because of the collector (AFAIK). I've fixed it by serialising the logging,
so that whole messages are written out and not broken up.
tests/hard_coded/tl_backjump_test.m:
As above.
This fixes a serious issue as `try' goals are not properly written to
.opt files, so when read back would not actually catch any exceptions.
Bug #420.
At the point where we are to create the .opt file, the pieces of a `try'
goal exist in a "pre-transformed" hlds_goal. Teasing apart the pieces to
resemble the original `try' goal would be non-trivial.
compiler/intermod.m:
Do not export any predicate or function with a clause containing a
`try' goal.
library/exception.m
Throw an exception if the dummy predicate
`magic_exception_result/1' is ever called.
tests/hard_coded/Mercury.options:
tests/hard_coded/Mmakefile:
tests/hard_coded/intermod_try_goal.exp:
tests/hard_coded/intermod_try_goal.m:
tests/hard_coded/intermod_try_goal2.m:
Add test case.
NEWS:
Announce change.
library/pretty_printer.m:
Make the changes indicated by the NOTE_TO_IMPLEMENTORS notes
in my previous change.
NEWS:
Announce the changes.
browser/browse.m:
tests/hard_coded/test_pretty_printer.m:
Conform to the above change.
library/version_array.m:
Add the above function.
Minor fixes to some comments.
tests/hard_coded/version_array_test.{m,exp}:
Extend this test to cover from_reverse_list/1 and
from_list/1.
NEWS:
Announce the addition.
tests/hard_coded/Mmakefile:
tests/hard_coded/string_case.m:
tests/hard_coded/string_case.exp:
Add tests for string.to_lower, string.to_upper and
string.compare_ignore_case_ascii.
library/list.m:
Make split_upto/4 and take_upto/{2,3} abort for N < 0.
tests/hard_coded/take_split_upto.{m,exp}:
Update this test case to test the for new behaviour.
tests/hard_coded/Mmakefile:
Do not run the take_split_upto test case in deep profiling
grades since it now requires catching exceptions to be supported.
NEWS:
Announce the above change.
library/time.m:
Deprecate non-pure functions `localtime/1' and `mktime/1'.
They depend on the current time zone, which depends on the
environment that the program is running in, and may also be
changed at run time (e.g. by setting the environment variable
"TZ").
Add replacement predicates `localtime/4' and `mktime/4' that
thread the I/O state.
Deprecate the non-pure function `ctime/1'. It does not seem
necessary to add a pure replacement for it, being a minor
convenience at best.
Try to clarify some documentation.
library/calendar.m:
Conform to above changes.
tests/hard_coded/dst_test.m:
tests/hard_coded/time_test.m
Conform to above changes.
Update code style.
extras/curs/samples/nibbles.m:
extras/graphics/easyx/samples/bounce.m:
extras/graphics/easyx/samples/mclock.m:
extras/log4m/log4m.m:
Conform to above changes.
NEWS:
Announce changes.
Improve documentation and test coverage for the same.
library/list.m:
Change the behaviour of take/3 and drop/3 so they fail if their
first argument is negative. This makes them consistent with
the behaviour of split_list/4 and is arguably less surprising than
their current behaviour.
Make split_list/4 more efficient by not doing two comparison
operations per recursive call.
Re-implement det_drop/3 in terms of drop/3.
Fix the documentation of the failure condition of split_list/4,
take/3 and drop/3; all three omitted the description of what
happens if their first argument is negative.
Use 'N' rather than 'Len' for the name of the first argument
in the comments describing the above predicates; the latter
is ambiguous.
NEWS:
Announce the change in behaviour of take/3 and drop/3.
tests/hard_coded/list_split_take_drop.{m,exp}:
Test the behaviour of the above predicates and also check that the
expected relationships between them hold.
tests/hard_coded/Mmakefile:
Add the new test.
Do this by insisting that terms whose top level(s) look like lambda
expressions should be parsed as lambda expressions, and return error
messages if that parsing attempt fails.
I did this is in several commits to modules in the parse_tree.m package
that translated terms to the parse tree, i.e. to goal_exprs. This diff
does the same thing for lambda expressions.
NEWS:
Document this change, as well as other, similar changes in the recent past.
compiler/superhomogeneous.m:
When translating a var-functor unification, which has the form
X = f(Y1, ..., Yn), to the HLDS, we parse the right hand side term,
looking for Mercury constructs such as lambda expressions and
field accesses. We used to do this by checking if the RHS was
a well-formed version of the construct we were looking for,
and falling back to parsing it as an ordinary term. That meant that
terms that the programmer *intended* to be lambda expressions,
but which contained a syntax error, were not diagnosed during the
construction of the HLDS, but during a later pass. Virtually always,
that later pass was typechecking. Since in such cases, the typechecker
is given terms whose function symbols were *intended* to be the "keywords"
of Mercury constructs (to the extent that Mercury *has* keywords),
not the names of data constructors or predicates, those error messages
were almost always confusing, and at best an *indirect* indication
of the actual problem with the code.
This diff changes things so that when the top function symbol on
the RHS of a unification is a Mercury "keyword" used only in lambda
expressions, we commit to parsing it as such. If the parsing fails,
we now generate an error message that describes the problem *directly*.
To make the task of generating good error messages easier, and to make it
possible to generate *consistent* error messages for the same error
in different contexts, unify the four separate pieces of code that
*used* to parse different kinds of lambda expressions. These four
pieces of code used to parse
- predicates defined using DCG notation;
- predicates defined using non-DCG notation;
- functions that used the default function mode and determinism; and
- functions that did not use the default function mode and determinism.
The unified code allows a function lambda expression to omit the
default argument modes *independently* of whether it omits the default
determinism, and vice versa. The old code did not do that: if you didn't
explicitly specify one, you couldn't explicitly specify the other either,
probably because it would have required two more pieces of code.
The language reference manual says, in section 8.1:
As with ‘:- func’ declarations, if the modes and determinism
of the function are omitted in a higher-order function term, then
the modes default to ‘in’ for the arguments, ‘out’ for
the function result, and the determinism defaults to ‘det’.
This text is vague on whether the modes and determinism are *allowed*
to be omitted independently. The old behavior was a strict reading
of this text. The new behavior follows the most liberal possible reading,
and thus allows all the behaviors that the old one did, and more.
Integrate the test for big integers that are too big to be represented
with the conversion of all ordinary functors into cons_ids, both to
simplify the code, and to speed it up. In the process, improve the
error message for too-big integers.
compiler/add_clause.m:
Don't try to generate warnings for singleton variables in a clause
if the clause had syntax errors. Part of the parser's recovery from
those syntax errors (e.g. when they occur in lambda expressions' clause
heads) may have included not translating parts of the original term
into the parsed clause body, so any such warnings could be misleading.
Such warnings could also be correct, but I expect most programmers
would prefer to miss some correct singleton warnings while the
syntax errors are present in their code, and get them only once
they have fixed those syntax errors, than to have to wade through
misleading errors messages for the initial syntax error to get to
the real ones.
compiler/field_access.m:
Clarify the text of an error message.
Delete a predicate that superhomogeneous.m no longer needs.
compiler/mercury_compile_front_end.m:
Don't proceed past typechecking if the parser found syntax errors,
since any errors we find later, e.g. as part of mode checking,
are quite likely to be avalanche errors caused by those syntax errors.
The reason why this wasn't a problem in the past is that when
the program contained malformed uses of builtin constructs such as
lambda expressions and field accesses, the parser used to simply
transform the terms containing the malformed constructs into the arguments
of call goals and unifications, and it was the typechecker that discovered
that these function symbols did not match any declared type.
The "type errors" generated for such problems told the compiler
not to run later compiler passes to prevent avalanche errors.
We now report syntax errors earlier, during the construction of the HLDS,
and it is entirely possible that the parser's recovery from those errors
leaves *no* type errors to be reported. This is why we need to make
the presence of syntax errors in a predicate block the invocation
of later passes.
compiler/typecheck.m:
Return whether the predicates we typechecked had syntax errors,
to make the change in mercury_compile_front_end.m possible.
compiler/state_var.m:
If a lambda expression has two or more arguments of the form !X,
we now print an error message for each, with each message naming the bad
state variable and giving the context of the argument. We used to
print only a single message saying that *some* argument misused
state variables this way. Similarly, we now print the correct context
for !X appearing as a function result, whether in a lambda expression
or at the top level of a clause.
The actual printing of those error messages takes place elsewhere,
but change the utility predicates exported by state_var.m to make
the change possible.
Change the error message we generate for !X appearing as a function
result, to avoid suggesting a possible repair that is virtually never
the right repair.
compiler/mode_util.m:
Delete a predicate that was used only by superhomogeneous.m; an updated
version of that predicate is now in superhomogeneous.m itself.
compiler/module_qual.m:
compiler/module_qual.qualify_items.m:
Instead of exporting predicates to module qualify the whole list of
argument modes of a lambda expression, export predicates that module
qualify only one such mode, since that is what superhomogeneous.m
now wants.
compiler/hlds_clauses.m:
Add access predicates for fields of the clauses_info type that previously
did not have them, including the one that records the presence of syntax
errors.
Put related fields of the clauses_info together.
Group both the declarations and the definitions of the access predicates
together, and put them in the same order as the fields themselves.
compiler/add_class.m:
compiler/add_pred.m:
compiler/add_pragma_type_spec.m:
compiler/higher_order.m:
compiler/hlds_pred.m:
compiler/unify_proc.m:
Conform to the changes above.
tests/invalid/lambda_syntax_error.err_exp:
Print one error message for each of the four malformed lambda expressions
in this test case, instead of the 13 avalanche messages we used to get
from the typechecker, which tried to interpret the malformed lambda
expression heads as calls, unifications etc.
The motivation for this diff was a set of similar set of avalanche error
messages for a real-life syntax error in a lambda expression in a change
I worked on a while ago.
tests/benchmarks/deriv.{m,exp}:
This test case used to use "^" as a data constructor (to represent
raising X to the Nth power). Since the parser now insists on treating it
as a field access operator, replace "^" with "power". (This test has
the excuse of predating the addition of field access syntax to Mercury
by several years.)
tests/dppd/grammar_impl.m:
This test case used to define a type which contained "is" as a data
constructor. After this diff, this is no longer allowed (as part of
"is detism", it looks to the parser like the top constructor in a
lambda expression head, and therefore as the top constructor of
the lambda expression as a whole if it has no body), so add the type
name as a prefix to this data constructor. To future-proof the test case,
do the same with the several other data constructors that also duplicate
the names of Mercury keywords.
tests/hard_coded/pprint_test2.{m,exp}:
tests/hard_coded/write.{m,exp}:
tests/hard_coded/write_binary.{m,exp}:
These test cases used to define a type which contained ":-" as a data
constructor. After this diff, this is no longer allowed, so replace them
with "?-". (The tests check how io.m formats terms whose data constructor
is an operator, so the replacement needs to be an operator, and Mercury
syntax does not use "?-"; library/ops.m lists it as an operator only
because it is an operator in Prolog.)
Update write_binary.m to conform to our current style guide, and to avoid
using the recently-deprecated io.make_temp.
tests/invalid/invalid_int.err_exp:
Expect the updated text of the error message for a too-big
integer constant.
tests/invalid/record_syntax_error.err_exp:
Expect the updated text of the error message for a malformed field name.
tests/invalid/state_vars_test3.err_exp:
Expect the updated text of the error message for a !X appearing
as the result of a lambda function.
tests/invalid/state_vars_test4.err_exp:
Expect the error message for a !X lambda argument, but (since we now
stop after typechecking in the presence of such syntax errors),
don't expect the avalanche error messages we used to print from the
mode checker.
library/io.m:
Use setenv() and _wputenv_s() to set environment variables
on C backends. Unlike putenv() and _wputenv(), these can be
relied upon to copy their inputs, so the inputs can safely
be garbage collected after the call returns.
tests/hard_coded/Mmakefile:
tests/hard_coded/setenv.{m,exp}:
Test case. Only run in grades for which io.set_environment_var/4
succeeds.
compiler/mlds_to_java.m:
We won't ever support mmake with Java, so delete it form the
TODO list.
compiler/options.m:
Delete references to grade components we no longer support.
compiler/rtti.m:
Delete a reference to the IL backend.
tests/hard_coded/pragma_foreign_export.m:
Delete an XXX: we have added a Java implementation and don't
need to add an IL one.
Currently we only allow non-primitive Java types to used with foreign_type
pragmas. This means that for foreign types that map on to Java primitive types
we have to use their boxed form (e.g. java.lang.Long, java.lang.Float etc) in
the foreign_type pragma. Doing so results in unnecessary boxing and is a
source of errors (e.g. accidently comparing for reference equality instead of
value equality).
This change causes the MLDS->Java code generator to recognise primitive
foreign_types and generate code that works for them directly. (In effect
their handling is not really different to how the builtin types are handled.)
doc/reference.texi:
Change the language so Java foreign types are allowed to be a
primitive Java types.
compiler/mlds_to_java.m:
Recognise foreign types that are defined as primitive types in Java and
generate code that avoids the need for (some) boxing of them.
library/array.m:
Handle arrays of Java bytes, shorts, longs and floats specially.
(boolean, char, int and double were already handled thus.)
NEWS:
Announce the above.
tests/hard_coded/Mmakefile:
tests/hard_coded/test_java_foreign_primitive.{m,exp}:
Test that foreign types work with primitive types in Java.
library/io.m:
Add predicates io.write_array/[56] which are are similar to
io.write_list but work on arrays and do _not_ require converting
the array into a list first.
library/array2d.m:
Add array2d.is_empty/1.
NEWS:
Announce the above additions.
tests/hard_coded/Mmakefile:
tests/hard_coded/write_array.{m,exp}:
Add a test for write_array.
tests/hard_coded/test_array2d.{m,exp}:
Extend this test to cover is_empty/1.
compiler/parse_item.m:
Don't accept `:- external' items.
compiler/prog_item.m:
Require the presence of a pred_or_func flag on external pragmas.
They are specified by `:- pragma external_{pred/func}' pragmas,
which are still supported.
compiler/parse_pragma.m:
When parsing external_{pred/func} pragmas, allow the predicate name
to contain a module qualifier; they were allowed on `:- external' items.
We do require the module qualifier to specify the expected (i.e. the
current) module.
compiler/add_pragma.m:
compiler/parse_tree_out_pragma.m:
compiler/recompilation.version.m:
Conform to the changes above.
tests/hard_coded/backend_external.m:
tests/hard_coded/constant_prop_2.m:
tests/invalid/external.err_exp:
tests/invalid/external.m:
tests/invalid/io_in_ite_cond.err_exp:
tests/invalid/io_in_ite_cond.m:
tests/invalid/overloading.m:
tests/invalid/tricky_assert1.m:
tests/invalid/type_spec.err_exp:
tests/invalid/type_spec.m:
tests/invalid/uniq_neg.err_exp:
tests/invalid/uniq_neg.m:
tests/valid/dcg_test.m:
tests/valid/inst_perf_bug_1.m:
tests/valid/lambda_recompute.m:
tests/valid/semidet_disj.m:
tests/valid/solv.m:
tests/valid/solver_type_bug.m:
tests/valid/stack_alloc.m:
tests/valid/tricky_assert2.m:
Replace `:- external' items with external_{pred/func} pragmas.
Modernize the code where needed, replacing DCGs with state variables.
In the Java grade, the standard streams were not being entered into the stream
database and the I/O globals were not being initialized. For executables,
generate a call to library.std_library_init/2 before main/2 is invoked. There
is still a problem for Mercury libraries called from Java programs and for
predicates specified in `:- initialise' declarations. For the latter, Mercury
requires that all standard library initialization be performed *before* any
user specified initialize predicates, but because we currently implement all of
this in Java using static initializers we can't guarantee that the order things
occur in.
The same issue affects the C# grade; I'll add a workaround for it separately.
library/io.m:
In the predicate io.init_state/2, in the Java grade do not
bother setting the current stream since for the standard text
streams we do so as part of class initialization and
library/library.m:
Export std_library_init/2 to Java.
compiler/mlds_to_java.m:
Generate a call to library.std_library_init/2 before main/2 is called.
XXX TODO we should roll the call that initializes the benchmarking module
into the same.
tests/hard_coded/Mmakefile:
tests/hard_coded/stdlib_init.{m,exp}:
Test that the stream database and globals in the io module are
initialized before main/2 is called.
tests/hard_coded/Mmakefile:
Don't run the solver_default_eq_cmp test in deep profiling grades
since it works by catching exceptions and the deep profiler doesn't
yet support that.
tests/hard_coded/remove_file.exp3:
Add an alternative expected output for this one. This current
output is the best we can do while we still support Java 1.5
and 1.6.
tests/hard_coded/remove_file.m:
Update syntax.
tests/hard_coded/Mmakefile:
Filter the Java and C# stack traces from the output of the no_fully_strict
test case.
tests/hard_coded/lexer_zero.exp3:
tests/hard_coded/write_reg1.exp5:
Alternative expected outputs due to difference in how floats are
printed.
