Re: Minor bug in cc-menus.el: cc-imenu-java-generic-expression does not match all Java 1.5+ function definitions.

[Nathaniel Flath <flat0103@gmail.com>]

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

There did turn out to be a few problems with that regexp - the updated one
is:

(defvar cc-imenu-java-generic-expression
  `((nil
     ,(concat
       "[" c-alpha "_][\]\[." c-alnum "_<> ]+[ \t\n\r]+" ; type spec
       "\\([" c-alpha "_][" c-alnum "_]+\\)" ; method name
       "[ \t\n\r]*"
       ;; An argument list htat is either empty or contains any number
       ;; of arguments.  An argument is any number of annotations
       ;; followed by a type spec followed by a word.  A word is an
       ;; identifier.  A type spec is an identifier, possibly followed
       ;; by < typespec > possibly followed by [].
       (concat "("
               "\\("
                  "[ \t\n\r]*"
                  "\\("
                     "@"
                     "[" c-alpha "_]"
                     "[" c-alnum "._]""*"
                     "[ \t\n\r]+"
                  "\\)*"
                  "\\("
                     "[" c-alpha "_]"
                     "[\]\[" c-alnum "_.]*"
                     "\\("
                        "<"
                        "[ \t\n\r]*"
                        "[\]\[.," c-alnum "_<> \t\n\r]*"
                        ">"
                     "\\)?"
                     "\\(\\[\\]\\)?"
                     "[ \t\n\r]+"
                  "\\)"
                 "[" c-alpha "_]"
                 "[" c-alnum "_]*"
                 "[ \t\n\r,]*"
               "\\)*"
              ")"
           "[ \t\n\r]*"
       "{"
       )) 1))
  "Imenu generic expression for Java mode.  See
`imenu-generic-expression'.")

I ended up just splitting out the annotations from the type from the
identifier name to make it easier in the argument list.  A file that
displays some of the matches/non-matches is:

//(setq imenu-generic-expression cc-imenu-java-generic-expression)

public class Test {

    void fun1() { }
    void fun2( int a ) { }
    void fun3( int a, int b ) { }
    List<String > fun4() { }
    Map< String,String > fun5() { }
    void fun6( @NonNull int a ) { }
    void fun7( @NonNull int b, @NonNull int c ) { }
    void fun8( @NonNull List<String> a ) { }
    void fun9( @NonNull List<List<String >> a ) { }
    void fun10( @NonNull int[] a) { }
    void fun11( List< class.innerclass > foo ) { }
    voif fun12( class.innerclass< Integer> foof ) { }

    else if( a ) { }
    else if( a < b ) { }
    else if( a < b && b > a ) { }
    else if(  a ) { }
    else if( a.b ) { }
}

the 'funX' should all be matched, with no 'else if's

On Tue, Jul 28, 2009 at 8:28 PM, Chong Yidong <cyd@stupidchicken.com> wrote:

> Alan Mackenzie <acm@muc.de> writes:
>
> > OK.  I've not looked at it in all that great detail, and haven't tried
> > it out yet.  I'm not actually a Java hacker.
> >
> > How confident are you that your proposed regexp won't spuriously match
> > things with "less than" or "greater than" tokens?  Or, if it will, would
> > these matches be rare enough that we needn't worry too much?
> >
> > Is there any chance you could send me a test file showing a typical
> > generic construct that the new regexp would match, and possibly
> > constructs with "less/greater than" which it "doesn't quite" match?
>
> By the way, it might be good to accumulate a test suite for CC mode,
> along the lines of etc/compilation.txt.  I don't know if you already
> have something like that; if so, we can put it in the new test/
> directory.
>
> (We should probably move etc/compilation into test/ also.)
>

[-- Attachment #2: Type: text/html, Size: 4727 bytes --]