3 Commits

Author	SHA1	Message	Date
Zoltan Somogyi	8355718b16	Allow pred pragmas to specify pred_or_func. ... Pragmas that apply to a pred_info have traditionally specified that pred_info by a symname/arity pair. However, this can be ambiguous if there is both a predicate and a function with that symname/arity pair. This diff therefore allows pragmas that previously took "symname/arity" to also take "pred(symname/arity)" and "func(symname/arity"). If e.g. there is both a pred foo/2 and a func foo/2 accessible from the current module, the old form applied to both, while the new forms apply to just one. Later, we could change the behavior of the old form to insist on a unique match, but before we do, we should have a mechanism that allows programmers to resolve the ambiguity. (They could rename either the pred or the func, but it is less intrusive for the compiler not to insist on that.) This is that mechanism. In the process of implementing this change, I had to update lots of code that dealt with arities, since one main difference between predicates and functions is that for the latter, the user visible arity and the internal compiler arity are different, in that the former does not count the return value, and the latter does. The existing "arity" type is an equivalence to int, and thus does not indicate which notion is meant. I therefore added two notag types, user_arity and pred_form_arity, for the two notions above respectively, and made a start on using them, though for now, only in the code sections affected by the main change above. compiler/prog_item.m: Change the types that represent the specifications of predicates (in the sense of pred_infos) and functions to allow the representation of not just "symname/arity," but also "pred(symname/arity)" and "func(symname/arity"). There is one exception: for the oisu (order independent state update) pragma, require the presence of either a pred() vs func() wrapper. This is not a breaking change, since oisu pragmas are neither publicly documented or really implemented. Pragmas that allow the representation of argument modes implicitly specify pred vs func by taking the mode list either as (m1, m2, ... mn) or as (m1, m2, ...) = mn. Encode this invariant in the representation type. Make this type also include an arity only in the absence of a mode list, to make unrepresentable any inconsistent state in which the stated arity and the length of the mode list disagree. Give the new types used for these updated representations names that state whether they specify a pred_info or a proc_info (or in one case that we should later fix, that they can specify either). Put the pred or func indication before the symname and arity both in these new types, and in some old types. Do this both because the pred or func indication comes before the name in Mercury declarations, and to help the compiler find all the places where code using the old forms had to be revisited and checked for any needed updates. Provide utility operations on the new types involved in the updated representations. compiler/prog_data.m: Add the user_arity and pred_form_arity types, as mentioned above. Add a type that is mostly used in item representations, but is also useful elsewhere. compiler/parse_pragma.m: compiler/parse_pragma_analysis.m: compiler/parse_pragma_foreign.m: compiler/parse_pragma_tabling.m: compiler/parse_util.m: Accept the pred() or func() wrappers mentioned above, and generate the updated representations when parsing terms containing pragmas. compiler/parse_tree_out_pragma.m: Accept the updated representations of pragmas when printing them out. compiler/add_pragma.m: compiler/add_pragma_tabling.m: compiler/add_pragma_type_spec.m: Use the updated representations when adding pragmas to the HLDS. compiler/error_util.m: Provide mechanisms for use above when printing references to pred_infos using user arities, to complement the existing mechanisms which use arities that they treat as pred form arities. The latter is what you want when generating error messages about pred_infos that already included functions' return types in the argument list; the former is what you want when generating error messages about user input that has not yet been subject to that treatment, such as a pragma that has just been read in. (The difference is only in what form of arity these mechanisms take as *input*; the output is always user arity, which after all is what users are interested in.) compiler/hlds_error_util.m: Provide a user_arity equivalent to a piece of existing pred_form_arity functionality, for use by the modules above. Provide utility functions used when generating error messages. compiler/fact_table.m: Replace most uses of the "arity" type with the "user_arity" type. Done mostly in the process of figuring out which kind of arity the top predicates took as arguments. Put argument lists into a sensible order. compiler/prog_out.m: compiler/prog_util.m: Add utility functionality needed above. compiler/add_mutable_aux_preds.m: compiler/convert_parse_tree.m: compiler/equiv_type.m: compiler/get_dependencies.m: compiler/intermod.m: compiler/item_util.m: compiler/make_hlds_passes.m: compiler/module_qual.qualify_items.m: compiler/recompilation.usage.m: compiler/recompilation.version.m: compiler/typecheck_errors.m: compiler/unused_args.m: Conform to the changes above. compiler/hlds_pred.m: Add an XXX. compiler/notes/order_indep_state_update: Fix typos. tests/hard_coded/bad_direct_reuse.m: tests/hard_coded/bad_indirect_reuse.m: tests/hard_coded/bitmap_simple.m: tests/hard_coded/constraint_order.m: tests/hard_coded/equality_pred_which_requires_boxing.m: tests/hard_coded/fact_table_test_1.m: tests/hard_coded/float_consistency.m: tests/hard_coded/foreign_enum_rtti.m: tests/hard_coded/foreign_enum_switch.m: tests/hard_coded/foreign_import_module_2.m: tests/hard_coded/gh72.m: tests/hard_coded/gh72a.m: tests/hard_coded/heap_ref_mask_tag.m: tests/hard_coded/intermod_multimode.m: tests/hard_coded/mode_check_clauses.m: tests/hard_coded/multimode_addr.m: tests/hard_coded/type_spec_ho_term.m: tests/hard_coded/user_defined_equality2.m: Add pred() or func() wrappers to symname/arity pairs in pragmas, to test whether the parser accepts them. Fix deviations from our current coding standards. tests/hard_coded/oisu_check_db.m: tests/invalid/oisu_check_add_pragma_errors.{m,err_exp}: tests/invalid/oisu_check_semantic_errors.m: Add the pred() wrappers now required in oisu pragmas. Expect the improved wording of an error message.	2021-05-06 07:19:25 +10:00
Zoltan Somogyi	63dabcfcf8	Fix filling in partial terms that use direct_arg tags. ... This fix uses the approach discussed on m-dev 2020 nov 16/17 for fixing github issue #72, whose core problem is a need for information flow back to a the caller from a callee when the callee fills in the argument of a function symbol whose representation is a direct_arg tag. In most cases when the callee fills in the value of an argument, the caller can see it because the argument is in a word on the heap, but when the function symbol uses a direct_arg tag, that is not the case. compiler/direct_arg_in_out.m: A new module that implements the transformation proposed on m-dev. It creates a fresh clone variable every time an argument of a direct_arg tag function symbol is (or may be) updated. This can happen several times if a type has more than one function symbol with a direct_arg tag. Since the affected variable can be bound to only one function symbol at the start, its argument can be filled in only once, but the compiler cannot know in advance what function symbol the variable contains, and therefore which of the possibly several fill-in sites (which fill in the arguments of different function symbols) executed in sequence will actually update the variable. The transformation ensures that once a variable is cloned, it is never referred to again. It also ensures that in a branched control structure (if-then-else, disjunction or switch), all branches will use the *same* variable to represent the latest version of each cloned variable at the end, so that following code has a consistent view regardless of through which branch execution has reached it. There are three situations that the transformation cannot and does not handle. 1. Situations in which the mode of an argument is either an inst variable, or an abstract inst. In either case, the pass cannot know whether it should apply its transformation to the argument. 2. Situations where a procedure that has such an argument is exported to C code as a function. In that case, the C signature of the function we would generate would be different from what the user would normally expect. We could modify the documentation of the export pragma, but I don't think there much point due to lack of demand. (The problem cannot arise when targeting any language other than C, because we use direct_arg tags only with the low level data representation, which we only use for C.) 3. Situations where a procedure that has such an argument is defined by foreign_proc. Again, dealing with the problem would require nontrivial changes to the documented interface between code in foreign_procs and the surrounding Mercury code, and I see no demand for code that could benefit from that. In these cases, this module generates error messages. compiler/transform_hlds.m: Include the new module in the transform_hlds package. Delete unnecessary module qualification on some existing inclusions. Put some existing inclusions into a more meaningful order. compiler/notes/compiler_design.html: Document the new pass. Fix some nearby prose. compiler/lambda.m: compiler/simplify_proc.m: Use a predicate exported by direct_arg_in_out.m to test, for each procedure, whether the procedure has any argument positions that are subject to the problem that direct_arg_in_out.m addresses. simplify_proc.m does this for all procedures it processes; lambda.m does this for all the procedures it creates from lambda expressions. Give a predicate in simplify_proc.m a better name. Sort a list of predicate names. compiler/hlds_module.m: Add a field to the module_info that simplify_proc.m and lambda.m can use to tell direct_arg_in_out.m what work (if any) it needs to do. compiler/mercury_compile_middle_passes.m: Invoke direct_arg_in_out.m if the new field in the HLDS indicates that it has some work to do. (In the vast majority of compiler invocations, it won't have any.) compiler/hlds_pred.m: The new code in direct_arg_in_out.m creates a clone of each procedure affected by the problem, before deleting the originals (to make sure that no references to the unfixed versions of now-fixed procedures remain.) Make it possible to create exact clones of both predicates and procedures by adding two pairs of predicates, {pred,proc}_prepare_to_clone and {pred,proc}_create. Add the direct_arg_in_out transformation as a possible source of transformed predicates. library/private_builtin.m: Add a new builtin operation, partial_inst_copy, that the new module generates calls to. configure.ac: Require the installed compiler to recognize partial_inst_copy as a no_type_info builtin. compiler/builtin_ops.m: Recognize the new builtin. (This was committed before the rest; the diff to private_builtin.m can be done only once the change to builtin_ops.m is part of the installed compiler.) compiler/options.m: Add a way to test whether the builtin_ops.m in the installed compiler recognizes the new builtin. compiler/dead_proc_elim.m: Do not delete the new primitive before direct_arg_in_out.m has had a chance to generate calls to it. Add an XXX. compiler/error_util.m: Recognize the new module as a source of error messages. compiler/pred_table.m: Add a pair of utility predicates to be used when looking up builtin predicates, for which the compiler writer knows that there should be exactly one match. These are used in direct_arg_in_out.m. compiler/simplify_goal_call.m: Replace some existing code with calls to the new predicates in pred_table.m. compiler/hlds_goal.m: Add modes to rename_vars_in_goal_expr that express the fact that when an atomic goal_expr has some variables renamed inside it, it does not suddenly become some *other* kind of goal_expr. New code in direct_arg_in_out.m relies on this. compiler/hlds_out_goal.m: When the HLDS we are dumping out is malformed because it contains calls to predicates that have been deleted, the compiler used to abort at such calls. (I ran into this while debugging direct_arg_in_out.m.) Fix this. When such calls are encountered, we now print out as much information we can about the call, and prefix the call with an unmistakable prefix to draw attention to the problem. compiler/inst_util.m: Fix a bug that prevented direct_arg_in_out.m from even being invoked on some test code for it. The bug was in code that we use to unify a headvar's initial inst with its final inst. When the initial inst was a non-ground bound_inst such as the ones used in tests/hard_coded/gh72.m, and the final inst was simply "ground", this code quite properly returned a bound_inst (which, unlike ground, can show the exact set of function symbols that the headvar could be bound to). The problem was that it reused the original bound_inst's test results, including the one that said the final inst is NOT ground, which of course is wrong for any inst unified with ground. Fix two instances of this bug. compiler/modes.m: Make some of the code I had to traverse to find the bug in inst_util.m easier to read and understand. Replace some uses of booleans with bespoke enum types. Change the argument lists of some predicates to put related arguments next to each other. Give some variables more descriptive names. compiler/layout_out.m: Conform to the change in hlds_pred.m. compiler/var_locn.m: Fix a code generation bug. When filling-in the value of the argument of a function symbol represented by a direct_arg tag, the code we generated for it worked only if the direct_arg tag used 0 as its ptag value. In the test cases we initially used for github issue 72, that was the case, but the new tests/hard_coded/gh72.m has direct_tag args that use other ptag values as well. Document the reason why the updated code works. compiler/term_constr_initial.m: Add the new primitive predicate added to private_builtin.m, partial_inst_copy, to a table of builtins that do not take type_infos, even though their signatures contain type variables. Fix a bunch of old bugs: most other such primitives were not listed either. mdbcomp/program_representation.m: Add partial_inst_copy to the master list of builtins that do not take type_infos even though their signatures contain type variables. (Done by an earlier commit.) Document the fact that any updates here require updates to term_constr_initial.m. library/multi_map.m: We have long had multi_map.add and multi_map.set as synonyms, but we only had multi_map.reverse_set. Add multi_map.reverse_add as a synonym for it. Define the "set" versions in terms of the "add" versions, instead of vice versa. NEWS: Document the new predicates in multi_map.m. tests/hard_coded/gh72a.m: Fix typo. tests/hard_coded/gh72.{m,exp}: A new, much more comprehensive test case than gh72a.m. This one tries to tickle github issue 72 in as many forms of code as I can think of. tests/invalid/gh72_errors.{m,err_exp}: A test case for testing the generation of error messages for two out of the three kinds of situations that direct_arg_in_out.m cannot handle. (Proposals for how to test the third category welcome.) tests/hard_coded/Mmakefile: tests/invalid/Mmakefile: Enable the two new test cases, as well as two old ones, gh72[ab].m, that previously we didn't pass. tests/invalid/Mercury.option: Do not compile gh72_error.m with --errorcheck-only, since its errors are reported by a pass that --errorcheck-only does not invoke.	2021-01-13 05:35:40 +11:00
Zoltan Somogyi	4b147be3f2	Add test cases for Github issue 72. ... Disable the test_generic_ref test case.	2019-08-27 11:26:07 +10:00