Estimated hours taken: 60
Branches: main
Redesign the way the declarative debugger tracks dependencies, to avoid bugs
and make the code comprehensible. This required tackling an issue we could
ignore before: the typeinfos added to procedure arguments by the compiler.
browsers/declarative_debugger.m:
Rewrite the dependency algorithm from scratch. It now has three phases:
materializing the contour leading up to the relevent point in the
procedure body, using that contour to construct a list of the conjoined
primitive operations executed up to that point by the procedure body,
and tracking the source of the marked subterm in this list of
primitives.
Add a mechanism to print out the result of the dependency tracking
algorithm if a flag is set, for testing and debugging.
browsers/declarative_analyser.m:
Transmit the result of the dependency tracking algorithm to where
it may be printed out.
browsers/declarative_user.m:
Update the user interface to make it switchable between viewing atoms
from the user's perspective (with compiler-generated arguments hidden)
and the implementor's perspective (with compiler-generated arguments
visible). The default view is the user view.
browsers/declarative_execution.m:
Add the immediate parent's goal path to the representation of call
events; this allows us to place the call in the body of its parent.
Expand the representation of atom arguments to include their HLDS
variable numbers, and a boolean that says whether the argument
is a programmer-visible headvar.
Use this extra information to add support for indexing lists of
arguments from either the user view or the implementor view.
Add field names to several types.
browsers/program_representation.m:
Add a field to plain calls, giving the name of the module defining
the called procedure. This is necessary to reliably distinguish
the builtin unify and compare procedures, calls to which must be
handled specially because they generate no events. (They don't need to,
since they are correct by construction.)
Add mechanisms for converting goal paths from strings to structured
terms, for use by the dependency tracking code.
Add tests on atomic goals, for use by the dependency tracking code.
Add a mechanism to let C code retrieve the types of proc_reps as well
as goal_reps.
compiler/prog_rep.m:
Fill in the module name field in plain calls.
trace/mercury_trace_vars.[ch]:
Add functions to get information about a variable specified by HLDS
number.
trace/mercury_trace_declarative.c:
Include typeinfos in the atoms constructed at interface events.
(The same code will work for typeclassinfos as well, once they
become deconstructable and hence printable.)
Fill in the extra slot in call events, and the extra slots in
representations of atom arguments.
trace/mercury_trace_internal.c:
Fix a bug in the implementation of the proc_body command: the
type of the proc_rep slot is proc_rep, not goal_rep.
tests/debugger/declarative/dependency.{m,inp,exp}:
A new test case to exercise dependency tracking. It cooperates with
instrumentation code in the browser directory to print out the result
of each trace_dependency operation.
The test case also tests the proc_body command.
tests/debugger/declarative/Mmakefile:
Enable the new test case.
Estimated hours taken: 2
Branches: main
Add two pieces of information that will be needed to an upcoming change
to the representation of procedure bodies in the declarative debugger.
The first piece is the full list of head vars. This is needed now because the
debugger no longer ignores variables of type type_info, and thus the Nth
headvar is no longer guaranteed to be variable number N. The second piece
is a cut/no_cut indicator in `some' goals. This is needed to allow us to
reconstruct goal paths exactly as we traverse goal representations.
browser/program_representation.m:
Make the two data structure changes described above.
browser/*.m:
Trivial changes to conform to the new data structures.
compiler/prog_rep.m:
Create the updated data procedure representation.
compiler/*.m:
Record and transmit the information needed by the updated procedure
representation.
runtime/mercury_stack_layout.h:
Update the documentation of the relevant field in proc_layouts.
Estimated hours taken: 8
Branches: main
Allow the browser to refer to fields by name.
browser/browser_info.m:
Generalize the data structure for recording paths within terms to allow
navigation by field names.
browser/browse.m:
browser/program_representation.m:
Update the algorithms for navigation in terms accordingly.
browser/parse.m:
Update the algorithm for reading in navigation terms.
Allow digits as well as letters and underscores in "names", since
field names may contain digits as well. This should not impact
other uses of names by the other parts of the debugger.
library/std_util.m:
Add new predicates named_argument and det_named_argument. They are
implemented using ML_named_arg, a new C function which is the same
as ML_arg except that it specifies the selected argument by name.
NEWS:
Mention the new predicates.
runtime/mercury_ml_expand_body.h:
Add a new alternative, EXPAND_NAMED_ARG, for use in implementing
ML_named_arg.
tests/debugger/field_names.{m,inp,exp,exp2}:
Expand this test case to exercise the browser.
Estimated hours taken: 40
Branches: main
This is the second part of a change to support term dependency analysis
in the declarative debugger. A `mark' command is implemented for the
term browser, which allows a particular subterm to be selected and
returned from the browser. The declarative debugger interprets this as
a suspicious subterm, and tries to find a child or sibling node from which
this subterm comes. This is used to determine the next question to be
asked of the oracle.
browser/browse.m:
Update the browser interface to allow for marked subterms being
returned from the browser.
Implement and document the mark command.
Rewrite run_command as a switch instead of a chain of if-then-elses.
This forces all unimplemented commands to be explicitly listed,
and gives better error checking.
browser/browser_info.m:
Add a maybe_mark field to the browser_info. It is initially `no',
but is updated when the mark command is given.
browser/declarative_analyser.m:
Select which child or sibling node to ask about next by searching
for the origin of the suspicious subterm. If the subterm has mode
`out' we act as if the oracle had answered no, and if the subterm
has mode `in' we act as if the oracle had answered yes. In future
we may not wish to presume this -- we do so now mainly to keep the
analysis algorithm simpler.
browser/declarative_debugger.m:
Add a functor for suspicious subterms to the decl_answer type.
browser/declarative_oracle.m:
Accommodate the changed answer type. The oracle does not try to
store information about suspicious subterms in the knowledge base,
because in principle this could lead to infinite loops (although
currently this wouldn't be a problem since we don't ever use the
information to move upward in the tree, so no cycle could be
formed).
browser/declarative_user.m:
Accommodate the changed answer type, and interpret marked terms
from the browser as suspicious subterms.
browser/parse.m:
Add the new command.
browser/program_representation.m:
Add a procedure to convert the browser's list(dir) to a term_path.
Change atomic_goal_rep_is_call/2 so it fails for special predicates,
which was originally intended.
trace/mercury_trace_browse.c:
Ignore the extra argument -- marked terms are not currently used in
the main debugger.
tests/debugger/declarative/Mmakefile:
tests/debugger/declarative/input_term_dep.*:
tests/debugger/declarative/output_term_dep.*:
tests/debugger/declarative/special_term_dep.*:
New test cases.
Estimated hours taken: 80
This is the first part of a change to support term dependency analysis
in the declarative debugger. A method is added to the mercury_edt
typeclass which finds the origin of a selected subterm in an EDT node,
somewhere in the body of the call or in the body of the parent. The
other parts of the change required before this can be useful are to
modify the search strategy (in browser/declarative_analyser.m) to make
use of the new information, and to modify the user interface to allow
a subterm to be selected. They will be committed as separate changes.
The typeclass method first traverses one or more contours, matching the
contour events up with goals in a procedure representation. This matching
process requires a left to right traversal, because we need to know which
disjunct/arm/branch was taken before we can match subgoals, and the
DISJ/SWTCH/THEN/ELSE events which tell us this information occur at the
left edge of the subgoals to which they apply. But we must always start
from the right hand side of the contour being traversed, so this means
that a right to left traversal is required before the matching can start.
Using the contour matched up with the atomic goals, we track the location
of a subterm by looking at which variables are bound, while scanning right
to left along the contour. Because this must happen after the matching,
this must be a separate right to left traversal than the earlier one.
Therefore the algorithm implemented here requires two passes over the
contours in order to find the origin of the selected subterm.
browser/declarative_execution.m:
Add a maybe(goal_rep) to call nodes in the annotated trace. This
is `no' if the relevant module was compiled below trace level `rep'.
trace/mercury_trace_declarative.c:
If the information is available, fill in the goal_rep when
constructing call nodes.
browser/declarative_analyser.m:
Add the new method to the mercury_edt typeclass.
browser/declarative_debugger.m:
Implement the new method. Update for the changed call nodes.
browser/program_representation.m:
Add a version of goal_paths to be used by the declarative debugger,
and a predicate to parse these from goal_path_strings. Add the
types arg_pos and term_path to represent a subterm of a call or exit.
browser/program_representation.m:
compiler/prog_rep.m:
No longer store conjunctions in reverse order in the goal_rep; we now
store them in the same order as in the HLDS.
Although we search conjunctions in reverse order, we need to match
them up with contour events before doing that. This can only be
done in the forwards direction, so it turns out that there is no
advantage in storing them in reverse order.
compiler/hlds_goal.m:
compiler/trace.m:
Add comments to the existing definitions of goal_path and
path_step_to_string.
Estimated hours taken: 0.75
Fix a bug which prevented bootstrapping in MLDS grades.
browser/program_representation.m:
Export to C a function ML_goal_rep_type() which returns the
type_info for a goal_rep.
trace/mercury_trace_internal.c:
Use ML_goal_rep_type(), rather than hard-coding the mangled
name for the type_ctor_info. (The hard-coded mangled name
was wrong for MLDS grades.)
Estimated hours taken: 20
Make procedure bodies available to the declarative debugger.
browser/program_representation.m:
Add _rep suffixes to the function symbols, to make iit easier to
distinguish HLDS goals and goal representations.
compiler/static_layout.m:
If --trace-decl is specified, include a representation of the procedure
body in the procedure's layout structure.
compiler/prog_rep.m:
A new module, containing the code that converts goals from HLDS
to a term in the format we want to put in the layout structure.
compiler/static_term.m:
A new module, containing the code that converts Mercury terms
to the LLDS rval we need to give to llds_out.m.
compiler/code_gen.m:
compiler/continuation_info.m:
Preserve the information needed by prog_rep
compiler/Mmakefile:
Extend the search path to the browser directory, since the new file
prog_rep.m imports one of the submodules of mdb.m stored there.
compiler/notes/compiler_desigm.html:
Document the new modules.
library/std_util.m:
Add a mechanism for static_term.m to use in converting terms into
rvals. This mechanism uses RTTI information to deconstruct terms,
and return not only their arguments, but also information about how
the term can be constructed from its arguments.
runtime/mercury_type_info.h:
Add a couple of macros to make construction and deconstruction of univs
easier, for use in std_util.m.
trace/mercury_trace_internal.c:
Add a new command, "proc_body", that prints out the representation
of the body of the current procedure. This is meant only for developers
to use to check that the procedure body representation is OK; it is
deliberately not documented.
Also fix a bug: make sure that we do not pass a NULL pointer to fputs
when echoing a line of input that isn't there (because we got EOF).
Estimated hours taken: 2
browser/program_representation.m:
New file to hold the definition of the representation of procedure
bodies to be used by the declarative debugger. This is committed now
so that Mark can write code to use this data structure while I write
code to generate it.
browser/mdb.m:
Mention the new module.
