Re: New scope checking patch

[Michael Snyder <msnyder@specifix.com>]

On Mon, 2007-11-12 at 16:29 +0000, Rob Quill wrote:
> Hi all,
> 
> The attached patch adds the ability to evaluate whether expressions
> are in scope without giving an error message. For example, if you were
> using a command file to control GDB then it it may not be ideal that
> the script stop executing due to a variable not being in scope at
> given position.

That's great!  I've often wanted something like that.

> 
> This patch allows you to say (for example)
> 
> while(the program is not finished)
> {
>     if($in_scope(x)) print x;
>     step;
> }
> 
> which would step through he whole program and print all the values of
> x where x is valid, and just continue stepping where it is not valid.
> 
> The bulk of the patch is changes to the evaluate_subexp functions in eval.c
> 
> The following cases are cases which the core is written for, but have
> not been tested yet:
> 
> case OP_SCOPE:
> case OP_REGISTER:
> case OP_STRING:
> case OP_OBJC_NSSTRING:		/* Objective C Foundation
> case OP_BITSTRING:
> case UNOP_MEMVAL:
> case UNOP_MEMVAL_TLS:
> case OP_OBJC_SELF
> 
> These cases have not been tested as I am unsure of code or commands
> which would allow me to test them. If anyone has any suggestions then
> that is greatly appreciated.
> 
> The following cases are unimplemented as I am unsure of how to check
> the scope of these expressions. Any advice you have is greatly
> appreciated.
> 
> case OP_ARRAY:
> case TERNOP_SLICE:
> case TERNOP_SLICE_COUNT:
> case TERNOP_COND:
> case OP_OBJC_SELECTOR:
> case OP_OBJC_MSGCALL:
> case OP_FUNCALL:
> case OP_F77_UNDETERMINED_ARGLIST:
> case STRUCTOP_PTR:
> case STRUCTOP_MEMBER:
> case STRUCTOP_MPTR:
> //	case TYPE_CODE_METHODPTR:
> //	case TYPE_CODE_MEMBERPTR:
> case MULTI_SUBSCRIPT:
> case UNOP_IND:
> 
> For example, I think for a function call the way to check scope should
> be to check that there is a function in scope with that name, and that
> all the parameters are in scope. However, I am unsure how to implement
> this.
> 
> TYPE_CODE_METHODPTR and TYPE_CODE_MEMBERPTR are commented out as they
> are supposedly redefinitions of two other cases (greater than and less
> than operators, I believe)
> 
> I should also point out that expression are evaluated without side
> effects, so that, for example $in_scope(a = b) will return 1 if a and
> b are in scope, but will not change the value of a.
> 
> There is a caveat with the patch which is as follows. If a variable is
> not in scope then the expression parser in c-exp.y inserts a value 0
> into the expression tree. When the scope checking function sees a 0
> expression in the tree it will return 0, to indicate not in scope.
> However, in the general case it should be true that all literals are
> in scope. However, due to the above caveat $in_scope(0) will return 0,
> any any other literal will return 1.
> 
> This also affects compound expressions that involve the literal 0. For
> example, $in_scope(0+3) will return 0, as an expression with a binary
> operator is considering in scope iff both of its operands are in
> scope.
> 
> Any thoughts on the patch are greatly appreciated.
> 
> Thanks.
> 
> Rob Quill