Re: [RFA] parse and eval breakpoint conditions with correct language

[Joel Brobecker <brobecker@gnat.com>]

> What gives me pause, though, is that the breakpoint_re_set_one isn't
> calling parse_exp_1 directly --- it's calling decode_line_1.  Are you
> going to propagate the language all the way through there?

Yes, it's the only approach I see.

> How do you see approaching this?

I think the safest way to approach this is by working from the bottom to
the top, in tiny steps that should be backward compatible in terms of
functionality.

Let's define the objectives:

  1. We want parse_exp_1 to take a language argument, so that it can
     use it to do the expression parsing.

  2. We want to take advantage of it when parsing a breakpoint condition
     For that, we need to be able to determine the language associated
     to a given block (or a given PC, whatever is more convenient)

  3. We want to take advantage of 1 to make sure we use the same language
     everytime we reparse the condition.

  4. We want decode_line_1 to take a language argument too, so that when
     we reset the breakpoints, we can use the same language as the
     language that was used when the breakpoint was first created.

  5. We want to fix the watchpoint problem that we also noticed.

I think these 5 steps can be done separately. Here is the plan:

  1. Add a language parameter to parse_exp_1. If NULL, then use
     current_language. Fix all the calls the parse_exp_1 to use
     NULL. As is, this change should be a nop.

  2. Pass the appropriate language to parse_exp_1 in the instances
     where we parse a condition. That includes modifying
     condition_command(), break_command_1(), do_captured_breakpoints().
     These changes are self-contained, as these procedures can determine
     on their own the appropriate language. This should fix the original
     problem I reported.

  3. Fix the call to parse_exp_1 in breakpoint_re_set_one to use the
     same language to reparse the condition. This is also
     self-contained.

  4. a. Add a language argument to decode_line_1() using the same
        nop approach as for 1.
     b. Fix the call to decode_line_1 in breakpoint_re_set_one so
        that the appropriate language is used to parse the given
        expression. That will allow us to remove the call to
        set_language, and will make sure that the second problem
        that I reported will not re-appear.
  
  5. Fix the problem of the wrong language used to reinsert watchpoints.
     For that we need to do:
     
     a. Add a language paramter to parse_expression(). Same as 1.
     b. Fix the call to parse_expression in breakpoint_re_set_one()
        to use the same language as before when reparsing the watchpoint
        expression.
  
The downside is that we will not end up reviewing the entire calling
tree to parse_exp_1, so we may leave some problems behind. But whatever
problems they are, we will be no worse than before. And the upside is
that a lot of the changes should be mechanical, and most of the patches
should be reasonably small and easy to review.
     
Shall I do that?
-- 
Joel