Commit Graph

3 Commits

Author SHA1 Message Date
Zoltan Somogyi
62d9fcbe4b Ignore (mostly) comments inside foreign_procs.
compiler/foreign.m:
    When returning the list of identifiers inside a foreign_proc's code,
    ignore the contents of comments. This means that warnings about
    variable names that occur in the foreign_proc's argument list
    but do not occur in the foreign_proc's code cannot be shut up anymore
    by mention the variable name in comments.

    The "mostly" part is that typecheck.m still looks at the bodies
    of foreign_procs without knowing about comments. Fixing that
    will be part a future change.

NEWS.md:
    Announce this breaking change.

compiler/fact_table_gen.m:
    When we try to generate a foreign_proc's body for a fact table
    but cannot do so due to the fact table file not being readable,
    add a marker to the predicate that the fact table is for.

compiler/hlds_markers.m:
    Update the documentation of the existing predicate marker
    we use for this.

compiler/make_hlds_warn.m:
    Do not warn about singleton variables in foreign_proc bodies
    that are empty due to missing fact table files.

library/array.m:
library/io.file.m:
library/profiling_builtin.m:
library/stm_builtin.m:
library/table_builtin.m:
library/term_size_prof_builtin.m:
tests/invalid/erroneous_throw_promise.m:
tests/invalid/foreign_procs_exist_type.m:
tests/invalid/foreign_purity_mismatch.m:
tests/invalid/gh72_errors.m:
tests/invalid_purity/purity.m:
tests/valid/solv.m:
    Shut up warnings about singletons in foreign_procs by adding a _ prefix
    to the names of the relevant arguments, and delete the comments
    that can no longer do that job.

tests/invalid/foreign_purity_mismatch.err_exp:
tests/invalid/gh72_errors.err_exp:
tests/invalid/gh72_errors.err_exp2:
tests/invalid/gh72_errors.err_exp3:
tests/invalid_purity/purity.err_exp:
    Expect updated line numbers.

tests/warnings/warn_return.{m,err_exp}:
    Extend this test case to test that

    - we DO warn about return statements outside comments, but
    - we DO NOT warn about return statements inside comments.
2026-01-28 13:34:30 +11:00
Zoltan Somogyi
f7a06c1f24 Fix a third batch of C# invalid test fails.
compiler/make.program_target.m:
    All the multimodule tests in tests/invalid_make_int have been failing
    in C# grades. The script for these tests has two main steps:

    - build all the .int3 files involved, and then
    - build the .int file.

    The second step is expected to fail, with its error messages being tested,
    but the first step is expected to succeed. The test cases were failing
    because mmc --make built the .int files as part of the FIRST stage.

    The cause was code that built all interface files (.int3, .int0,
    .int/.int2 and even .opt) as a preliminary first step before actually
    trying to act on *any* build-all target. The fix is to make this
    preliminary step build only the interface files that come before
    the build-all target's file kind in the build order. In this case,
    that means not building anything in the preliminatu step of the
    build-all-int3s target before building all the .int3s, thus leaving
    the construction of the .int file for the second step, which is
    *expected* to fail.

tests/invalid/exported_unify_helper_1.m:
    Rename exported_unify2.m to exported_unify_helper_1.m in accordance
    with our usual scheme.

tests/invalid/exported_unify.{m.err_exp,err_exp2}:
    Update both expected error files for the rename. Since the .err_exp2 file
    was ancient, this update fixed the test case failure for C# (and almost
    certainly for Java) bootchecks. Note the role of each expected output
    file in the source code.

tests/invalid/foreign_procs_exist_type.err_exp2:
tests/invalid/foreign_procs_exist_type.err_exp3:
    Add these files containing the expected outputs for Java and C#.

tests/invalid/foreign_procs_exist_type.m:
    Add a note about the role of each expected output file.

tests/invalid/foreign_procs_exist_type.err_exp:
    Update the line numbers for this file containing the C expected output.

tests/invalid/foreign_purity_mismatch.m:
tests/invalid/fp_dup_bug.m:
    For each C foreign proc being tested, add C# and Java foreign_procs
    as well.

    Add a note about the role of each expected output file.

tests/invalid/foreign_purity_mismatch.err_exp2:
tests/invalid/foreign_purity_mismatch.err_exp3:
tests/invalid/fp_dup_bug.err_exp2:
tests/invalid/fp_dup_bug.err_exp3:
    Add these files containing the expected outputs for Java and C#.

tests/invalid/foreign_purity_mismatch.err_exp:
tests/invalid/fp_dup_bug.err_exp:
    Update the line numbers for this file containing the C expected output.

tests/invalid/gh72_errors.m:
    This test case tests an error message from the direct arg transformation.
    This transform does not apply to C# and Java grades, so in those grades,
    the compiler does not generate those messages. In those grades, this
    test case failed because the compilation succeeds, instead of failing
    (with the expected message, or not).

    Fix this failure by adding to gh72_errors.m C# and Java foreign_procs
    that do get error messages.

tests/invalid/gh72_errors.err_exp2:
tests/invalid/gh72_errors.err_exp3:
    Expect these error messages in C# and Java grades respectively.

tests/invalid/gh72_errors.err_exp:
    Update the line numbers in the error messages during C compilations.
2023-10-26 08:47:39 +11: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