Commit Graph

4 Commits

Author SHA1 Message Date
Zoltan Somogyi
e35a09542e Print two kinds of ambiguities only if asked for.
trace/mercury_trace_cmd_developer.c:
trace/mercury_trace_tables.[ch]:
    Add two options to the mdb command "ambiguity".

    Print ambiguities between function and predicate forms of the same
    operation, such as list.length, only if the new option -b, or
    --both-pred-and-func, is given.

    Print ambiguities involving procedures that were created by type
    specialization only if the new option -s, or --typespec is given.
    (The -t option name was already taken.)

    These changes remove from the ambiguity command's output
    (some of) the parts that are not useful when one wants to eliminate
    ambiguities by renaming.

    Clarify a heading.

doc/user_guide.texi:
    Document the above changes.

runtime/mercury_proc_id.h:
    Fix a field name that has become misleading.

    MR_UserProcId_Structs have a field named MR_user_arity.
    In this name, the "MR_user_" part is a prefix shared by the other
    fields in that structure, to indicate that they are part of the id
    of a user-defined procedure, as opposed to a compiler-created
    unify, compare or index procedure. However, the arity it contains
    is what the compiler now calls a pred_form_arity: it does not count
    type_info and typeclass_info arguments added by polymorphism, but
    it *does* count function return values for functions. This is now
    misleading, because in the compiler, a user_arity does *not* count
    function return values for functions.

    Replace this field name with MR_user_pred_form_arity, which tells
    readers that this arity is a pred_form_arity. The presence of the
    "user" part of the name may still cause some confusion, but at least
    that confusion should motivate readers to look up the field name,
    whose comment should clarify things.

mdbcomp/rtti_access.m:
runtime/mercury_debug.c:
runtime/mercury_deep_profiling.c:
runtime/mercury_ho_call.c:
runtime/mercury_layout_util.c:
runtime/mercury_ml_expand_body.h:
runtime/mercury_stack_layout.h:
runtime/mercury_trace_base.c:
trace/mercury_trace.c:
trace/mercury_trace_external.c:
trace/mercury_trace_util.c:
    Conform to the change in mercury_proc_id.h.

tests/debugger/ambiguity.{m,inp,exp}:
tests/debugger/ambiguity_helper.m:
    Expand this test case to test the new functionality.
    The type specialized predicates are in a new helper module,
    because this is the simplest way to avoid dead procedure elimination
    deleting any of the predicates whose names we want to test for ambiguities.
2022-07-05 08:00:12 +10:00
Zoltan Somogyi
33eb3028f5 Clean up the tests in half the test directories.
tests/accumulator/*.m:
tests/analysis_*/*.m:
tests/benchmarks*/*.m:
tests/debugger*/*.{m,exp,inp}:
tests/declarative_debugger*/*.{m,exp,inp}:
tests/dppd*/*.m:
tests/exceptions*/*.m:
tests/general*/*.m:
tests/grade_subdirs*/*.m:
tests/hard_coded*/*.m:
    Make these tests use four-space indentation, and ensure that
    each module is imported on its own line. (I intend to use the latter
    to figure out which subdirectories' tests can be executed in parallel.)

    These changes usually move code to different lines. For the debugger tests,
    specify the new line numbers in .inp files and expect them in .exp files.
2015-02-14 20:14:03 +11:00
Zoltan Somogyi
648f29c06f Extend the mdb command "ambiguity" to report information about not just
Estimated hours taken: 3
Branches: main

Extend the mdb command "ambiguity" to report information about not just
ambiguous procedure names and type constructor names but also ambiguous
function symbols.

trace/mercury_trace_tables.[ch]:
	Implement the new capability.

	Declare some static functions at the top of the file before
	their definitions.

trace/mercury_trace_cmd_developer.c:
	Add new options -p, -t and -f that allow the user to select the
	printing of ambiguity information about procedure names, type
	names and/or function symbols.

doc/user_guide.texi:
	Document the new functionality and options.

trace/mercury_trace_spy.c:
	Minor style fix.

tests/debugger/ambiguity.{m,exp}:
	Extend this test case to test the new functionality, and update the
	expected output.
2006-08-20 05:41:45 +00:00
Zoltan Somogyi
0ecbc0efb0 Fix some bugs in the mdb "ambiguity" command, and add an enhancement to it.
Estimated hours taken: 2
Branches: main

Fix some bugs in the mdb "ambiguity" command, and add an enhancement to it.

doc/user_guide.texi:
	Document the enhancement: users can now restrict the set of modules
	in which the debugger looks for ambiguity.

tests/debugger/ambiguity.{m,inp,exp}:
	A new test case to check the new functionality and the bug fix.

tests/debugger/Mmakefile:
	Enable the new test.

trace/mercury_trace_tables.[ch]:
	Fix two bugs in the implementation of the function that implements
	the ambiguity command. One was that we neglected to differentiate
	between predicates and functions of the same name and arity. Another
	was that for functions, we used the wrong arity: the one after the
	addition of the result as an argument, not the one before.

	Add the ability to restrict the search to a list of named modules.

trace/mercury_trace_internal.c:
	Update the parsing of the command line for ambiguity commands to allow
	users to specify lists of module names.

	Fix an old bug, and make sure it never happens again. We used to
	pass the category and name of the current command every time we
	reported a syntax error, or called an option parsing routine (since it
	may have to report a syntax error). Since much of this code is best
	done via cut-and-paste, we often passed the wrong strings. For example,
	before this fix, a syntax error in an ambiguity command lead to a
	suggestion to do "help class_decl"!

	The fix is simply to record the category and name of the current
	command in a pair of variables, and refer to these variables when
	reporting syntax errors.

	Note that there are still mismaches in the names of categories
	between mercury_trace_internal.c and user_guide.texi. These should
	be fixed, but for now things are fine, since our current error messages
	don't include the category name.
2006-03-01 22:58:51 +00:00