RE: [RFA] Add ObjC recognition to linespec.c [5/5]

Adam Fedor
2003-01-07T13:56:30Z

> -----Original Message-----
> From: Elena Zannoni [mailto:ezannoni@redhat.com]
> Sent: Monday, January 06, 2003 3:27 PM
> To: Adam Fedor
> Cc: GDB Patches
> Subject: Re: [RFA] Add ObjC recognition to linespec.c [5/5]
>
>
[...skipped...]
>
> > + if (*p && (p[0] == ':') && (strchr ("+-", p[1]) != NULL)
> > + && (p[2] == '['))
> > + {
> > + is_objc_method = 1;
> > + paren_pointer = NULL; /* Probably just a category
> name. Ignore it */
> > + }
> > +
>
> If you find a parenthesis what exactly does that mean? I.e. why are
> you making it null again, ignoring what set_flags has found?
>

The paren_pointer is (I think) used for C++ overload checking, in Objective-C that isn't necessary, but you may have something like

break -[MyObject(PrivateCategory) someMethod:]

where the paren_pointer code gets hung up on the 'PrivateCategory' specification when it should just ignore this and skip past the whole method specification (The whole thing gets handled in decode_objc.)

> > + /* Is it an Objective-C selector? */
> > +
>
> What form does a selector have? Could you add that in the comment?
>

I could, but a selector can have almost any form, from completly unqualified ('break isFlipped') to fullly qualified ('break -[MyObject isFlipped]').

> > + {
> > + struct symtabs_and_lines values;
> > + values = decode_objc (argptr, funfirstline, NULL,
> > + canonical, saved_arg);
> > + if (values.sals != NULL)
> > + return values;
> > + }
> > +
> > /* Does it look like there actually were two parts? */
> >
> > if ((p[0] == ':' || p[0] == '.') && paren_pointer == NULL)
>
> this check above will trigger for the objc methods, right? If so, do
> decode_compound and symtab_from_filename do the right things for objc
> methods?
>

If it's an objc method it gets handled in decode_objc, otherwise it is handled correctly in decode_compound, etc.

> > @@ -669,13 +699,21 @@ decode_line_1 (char **argptr, int funfir
> > Find the next token (everything up to end or next
> whitespace). */
> >
> > if (**argptr == '$') /* May be a convenience
> variable */
> > - p = skip_quoted (*argptr + (((*argptr)[1] == '$') ? 2
> : 1)); /* One or two $ chars possible */
> > + {
> > + /* One or two $ chars possible */
> > + p = skip_quoted (*argptr + (((*argptr)[1] == '$') ? 2 : 1));
> > + }
> > else if (is_quoted)
> > {
> > p = skip_quoted (*argptr);
> > if (p[-1] != '\'')
> > error ("Unmatched single quote.");
> > }
> > + else if (is_objc_method)
>
> I wonder if the check above that sets is_objc_method needs to be done
> that early, and couldn't be instead moved to here (thinking out
> loud).
>

Yes you could, except it's also needed for the paren_pointer check.

> > + {
> > + /* allow word separators in method names for Obj-C */
> > + p = skip_quoted_chars (*argptr, NULL, "");
> > + }
> > else if (paren_pointer != NULL)
> > {
> > p = paren_pointer + 1;
> > @@ -952,6 +990,13 @@ locate_first_half (char **argptr, int *i
> > error ("malformed template specification in command");
> > p = temp_end;
> > }
> > + /* Check for a colon and a plus or minus and a [ (which
> > + indicates an Objective-C method) */
> > + if (*p && (p[0] == ':') && (strchr ("+-", p[1]) != NULL)
> > + && (p[2] == '['))
> > + {
> > + break;
> > + }
> > /* Check for the end of the first half of the
> linespec. End of line,
> > a tab, a double colon or the last single colon,
> or a space. But
> > if enclosed in double quotes we do not break on
> enclosed spaces */
> > @@ -993,6 +1038,98 @@ locate_first_half (char **argptr, int *i
> > }
> >
> > \f>
> > +
> > +struct symtabs_and_lines
> > +decode_objc (char **argptr, int funfirstline, struct
> symtab *file_symtab,
> > + char ***canonical, char *saved_arg)
> > +{
> > + /* here's where we recognise an Objective-C Selector. An
> > + * Objective C selector may be implemented by more than one
> > + * class, therefore it may represent more than one
> > + * method/function. This gives us a situation somewhat
> > + * analogous to C++ overloading. If there's more than one
> > + * method that could represent the selector, then use some of
> > + * the existing C++ code to let the user choose one.
> > + */
> > +
>
> Comments should go before the function. Also, sentences should be
> capitalized, end with a '.' and 2 spaces after the period.
> (yes, it's a
> pain). (No asterisks either).
>
[...]

OK. I'll update the patch (splitting the two functions into separate patches also).