mirror of
https://github.com/Mercury-Language/mercury.git
synced 2026-04-15 01:13:30 +00:00
e35a09542e
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.
This directory holds the trace subsystem, i.e. the part of the Mercury debugger that is written in C code. Notes on interfacing with other subsystems ------------------------------------------ If tracing is enabled, the compiler includes calls to MR_trace() in the generated C code. The trace subsystem in this directory is therefore called directly from Mercury code, via MR_trace() in runtime/mercury_trace_base.c. One of the first things it does is to save the original values of the Mercury registers in a variable called `saved_regs'. The reason it needs to do this is that the code here may modify registers, e.g. by allocating memory using incr_hp or by calling Mercury code. Once the original values of the registers have been saved, the trace subsystem is free to modify the Mercury registers. So for all code in this directory, the usual convention is that the original values of the Mercury registers are in `saved_regs', while the current (scratch) values for the normal non-transient Mercury registers etc. are in their normal locations, not in the fake_reg copies, and the transient (register window) registers, if any, are in the fake_reg copies. Any code which uses macros such as incr_hp(), list_cons(), make_aligned_string(), etc. that modify the heap pointer must call restore_transient_regs() beforehand and must call save_transient_regs() afterwards. The simplest way to do this is to use the macro MR_TRACE_USE_HP() in trace/mercury_trace_util.h. The tracer may invoke Mercury code defined in the browser or library directories if that code is exported to C using `pragma export'. But any calls from functions here to code defined in Mercury and exported using `pragma export', i.e. functions starting with `ML_' prefixes, must be preceded by a call to save_registers() and followed by a call to restore_registers(). The simplest way to do this is to use the macro MR_TRACE_CALL_MERCURY() in trace/mercury_trace_util.h.