This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: New scope checking patch
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
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;