Re: New scope checking patch

["Rob Quill" <rob.quill@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3914 bytes --]

On 17/01/2008, Jim Blandy <jimb@codesourcery.com> wrote:
>
> "Rob Quill" <rob.quill at gmail.com> writes:
> > On 17/01/2008, Jim Blandy <jimb@codesourcery.com> wrote:
> >> Also, please be sure that the indentation follows the GNU coding
> >> conventions.  Substatements should be indented by two spaces.
> >> (c-exp.y is not a great place to look for examples, since it's a mess,
> >> but look at, say, frame.c.)
> >>
> >> From looking at your patch as it arrived through my mailer, it seemed
> >> that the code block for the new $in_scope grammar rule was not
> >> indented in the same way as the other blocks.  These should all be
> >> consistent.
> >
> > Hey,
> >
> > Sorry about getting the formatting consistently wrong. I've
> > reformatted it and it looks to me like it matches the other cases,
> > although it is hard to tell where to use tabs and where to use spaces,
> > and I'm never sure it's right as what if I have a different tab size
> > to you etc. I tried putting it through indent, but that just made a
> > mess, although as a rule is it OK to use that if it is a C file?
>
> I'm told Open Source projects avoid tabs, but it seems that GDB
> permits them, with tab stops every 8 columns.  The GNU coding
> standards don't say much about tab use or width, beyond saying that
> error messages that include line and column numbers should assume tab
> stops every 8 columns when computing column numbers.
>
> We don't generally use indent; if you look through the mailing list
> archives, you can see the arguments.  I can only remember the
> arguments that made sense to me, so I'm not sure I can accurately
> explain the reasoning.  :)
>
> If you use GNU Emacs C mode with the default settings, then TAB, C-j,
> and C-M-q will do the right thing.
>
> > +                       if (!have_full_symbols () && !have_partial_symbols ())
> > +                             error ("No symbol table is loaded.  Use the \"file\" command.");
>
> Too much indentation?

Well, you would think so, but I've changed the tab spacing in vim to 8
and the way I have formatted it matches how everything else is
formatted.

> > +
> > +                       /* Otherwise, prepare to write out the value */
> > +                       int_type = builtin_type (current_gdbarch)->builtin_int;
> > +                       write_exp_elt_opcode (OP_LONG);
> > +                       write_exp_elt_type (int_type);
> > +
> > +                       min_symbol =
> > +                         lookup_minimal_symbol (copy_name($3.stoken), NULL, NULL);
> > +                       if ($3.sym || min_symbol)
> > +                         write_exp_elt_longcst ((LONGEST) 1);
> > +                       else
> > +                         write_exp_elt_longcst ((LONGEST) 0);
>
>
>
> > +
> > +                       write_exp_elt_opcode (OP_LONG); }
>
> Closing brace should get its own line, since the opening brace did.

This is what I thought too, but if you look at the rest of the file
(for example the case for "exp : exp ARROW name") the open brace
always starts on a new line and always ends on the same line.

>
> > @@ -1678,6 +1704,9 @@ yylex ()
> >    /* Catch specific keywords.  Should be done with a data structure.  */
> >    switch (namelen)
> >      {
> > +     case 9:
> > +       if (strncmp (tokstart, "$in_scope", 9) == 0)
> > +     return IN_SCOPE;
> >      case 8:
> >        if (strncmp (tokstart, "unsigned", 8) == 0)
> >       return UNSIGNED;
>
> When I view this (again, with 8-column tab stops), the 'case' is not
> lined up with the other cases, and the 'return' is not indented two
> spaces within the 'if'.

Sorry, missed that. I've attached the fixed copy. I believe that the
amount of indentation matches the layout of the current file, and that
even though it looks like a lot in the context of the patch, all the
other grammar rules in the file use the same large amount of
indentation.

Rob

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: in_scope.patch --]
[-- Type: text/x-diff; name=in_scope.patch, Size: 1687 bytes --]

Index: gdb/c-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/c-exp.y,v
retrieving revision 1.42
diff -u -p -r1.42 c-exp.y
--- gdb/c-exp.y	9 Jan 2008 19:27:15 -0000	1.42
+++ gdb/c-exp.y	18 Jan 2008 03:32:41 -0000
@@ -208,6 +208,8 @@ static int parse_number (char *, int, in
 %token TRUEKEYWORD
 %token FALSEKEYWORD
 
+/* $in_scope opperator */
+%token IN_SCOPE
 
 %left ','
 %left ABOVE_COMMA
@@ -251,6 +253,30 @@ exp1	:	exp
 	;
 
 /* Expressions, not including the comma operator.  */
+exp	:	IN_SCOPE '(' name_not_typename ')'
+			{
+			  struct type *int_type;
+			  struct minimal_symbol *min_symbol;
+
+			  /* If there are no symbols then just stop right away */
+			  if (!have_full_symbols () && !have_partial_symbols ())
+				error ("No symbol table is loaded.  Use the \"file\" command.");
+
+			  /* Otherwise, prepare to write out the value */
+			  int_type = builtin_type (current_gdbarch)->builtin_int;
+			  write_exp_elt_opcode (OP_LONG);
+			  write_exp_elt_type (int_type);
+
+			  min_symbol = 
+			    lookup_minimal_symbol (copy_name($3.stoken), NULL, NULL);
+			  if ($3.sym || min_symbol)
+			    write_exp_elt_longcst ((LONGEST) 1);
+			  else
+			    write_exp_elt_longcst ((LONGEST) 0);
+
+			  write_exp_elt_opcode (OP_LONG); }
+	;
+
 exp	:	'*' exp    %prec UNARY
 			{ write_exp_elt_opcode (UNOP_IND); }
 	;
@@ -1678,6 +1704,9 @@ yylex ()
   /* Catch specific keywords.  Should be done with a data structure.  */
   switch (namelen)
     {
+    case 9:
+      if (strncmp (tokstart, "$in_scope", 9) == 0)
+	return IN_SCOPE;
     case 8:
       if (strncmp (tokstart, "unsigned", 8) == 0)
 	return UNSIGNED;