mirror of
https://github.com/Mercury-Language/mercury.git
synced 2026-04-16 09:53:36 +00:00
b666df73db
compiler/hlds_module.m:
The module info has long contained three fields that map
contexts to counters, which are intended to supply a disambiguating
sequence number in case multiple entities that need separate names
end up on the same line number. However, while these fields map
full contexts (i.e. filename/linenumber pairs) to the counters,
the resulting sequence numbers are used to construct predicate names
that do NOT include the file number. This allows a kind of collision,
which the simple change to parse_tree_out_item.m below just happened
to trigger.
The problem was that test_bitset.m
- imports both fat_spatse_bitset and fatter_spatse_bitset,
- with --flags INTER_FLAGS, mmc reads both fat_spatse_bitset.opt
and fatter_spatse_bitset.opt,
- both of those .opt files happended to have a function
lambda expression on the same line.
Since the filename parts of the contexts were different, both
lambda expressions were given sequence number 1, which meant that
the two functions that implement the two lambdas ended up with
the same name, which the C compiler objected to.
The fix is to change the type of the lambda context map
from map(prog_context, counter) to map(int, counter), with
the int being the line number.
Apply the same fix to the other two maps of the same type,
which are for loop invariants and atomic goals respectively,
since they are vulnerable in the exact same way.
But since it seems that atomic goal map was not actually used,
comment it out, and move the loop invariant map next to the
map for lambdas.
compiler/lambda.m:
compiler/loop_inv.m:
Conform to the changes above.
compiler/parse_tree_out_item.m:
Print each argument of a data constructor in a type definition
on its own line. This affected the two .opt files named above
*just* enough to put the two lambda functions on the same line number.
The motivation was that without this change, looking at the
definition of the opt_tuple type in libs.optimization_options.int
gives you an overwhelming wall of text.
tests/misc_tests/pretty_print_test.exp:
Expected the effect of the change to parse_tree_out_item.m
on this ugly-print test.