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

["Adam Fedor" <fedor@doc.com>]

> -----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).