[m-rev.] for review: breakpoints on line numbers

[Julien Fischer]

On Fri, 7 Aug 2020, Zoltan Somogyi wrote:

> For review by anyone. The main thing I am looking for feedback on
> is whether we can rely on limits.h for INT_MAX, or whether there is
> a more portable solution.

That is the portable solution!

(In theory, INT_MAX may not be big enough since Mercury doesn't actually
impose any limit on how large the line number in a #line directive can
be; C does impose such a limit -- for C99 it is 2147483647.)

> Improve an mdb error message.
> 
> trace/mercury_trace_spy.c:
>     When the user wants to put a breakpoint on a line in a file,
>     but there is no event exactly on the given line number,
>     mdb used to tell the user just that fact. This diff makes
>     mdb more helpful, by printing the nearest line numbers before
>     and after the given line number that *do* have events on which
>     breakpoints can be put.
>
>     The mismatch can come for several reasons, with the most common
>     probably being that textuall, a switch arm for e.g X being f

s/textuall/textual/

>     starts with the X = f unification goal, but switch detection
>     *deletes* that unification from the switch arm, so the event
>     for entry into that arm is actually on the line for the *next* goal.
> 
> trace/mercury_trace_tables.[ch]:
>     Provide the info needed by mercury_trace_spy.c.
>
>     Change the interface of MR_process_file_line_layouts to make it
>     self-contained, i.e. returning counts of matches, instead of
>     merely *adding* to preexisting counts. This is simpler, since
>     the only caller of that function needs no running tally.
> 
> tests/debugger/breakpoints.inp:
>     Extend this test to test the possible error messages we now generate.
> 
> tests/debugger/breakpoints.exp:
> tests/debugger/breakpoints.exp2:
>     Update the expected outputs in both debug and non-debug grades.

That looks fine otherwise.

Julien.