git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrei Rybak <rybak.a.v@gmail.com>
To: Johannes Sixt <j6t@kdbg.org>, git@vger.kernel.org
Cc: Jeff King <peff@peff.net>, Paolo Bonzini <pbonzini@redhat.com>,
	Tassilo Horn <tsdh@gnu.org>
Subject: Re: [PATCH v3 1/3] userdiff: support Java type parameters
Date: Wed, 8 Feb 2023 01:04:26 +0100	[thread overview]
Message-ID: <152251b7-79a1-9ea9-01de-61a68b729196@gmail.com> (raw)
In-Reply-To: <20230207234259.452141-2-rybak.a.v@gmail.com>

On 2023-02-08T00:42, Andrei Rybak wrote:
> A class or interface in Java can have type parameters following the name
> in the declared type, surrounded by angle brackets (paired less than and
> greater than signs).[2]   The type parameters -- `A` and `B` in the
> examples -- may follow the class name immediately:
> 
>      public class ParameterizedClass<A, B> {
>      }
> 
> or may be separated by whitespace:
> 
>      public class SpaceBeforeTypeParameters <A, B> {
>      }
> 
> A part of the builtin userdiff pattern for Java matches declarations of
> classes, enums, and interfaces.  The regular expression requires at
> least one whitespace character after the name of the declared type.
> This disallows matching for opening angle bracket of type parameters
> immediately after the name of the type.  Mandatory whitespace after the
> name of the type also disallows using the pattern in repositories with a
> fairly common code style that puts braces for the body of a class on
> separate lines:
> 
>      class WithLineBreakBeforeOpeningBrace
>      {
>      }
> 
> Support matching Java code in more diverse code styles and declarations
> of classes and interfaces with type parameters immediately following the
> name of the type in the builtin userdiff pattern for Java.  Do so by
> just matching anything until the end of the line after the keywords for
> the kind of type being declared.

The above explains why removing the mandatory matching for whitespace
after the class name is needed, but it doesn't explain why removing
the part of the regex that matches the class name itself is OK.
Perhaps, something like this could be added:

     An possible approach could be to keep matching the name of the
     type: "...[ \t]+[A-Za-z][A-Za-z0-9_$]*.*)$\n", but without matching
     mandatory whitespace after the name of the type, matching the name
     itself separately isn't useful for our purposes.

?

> [1] Since Java 5 released in 2004.
> [2] Detailed description is available in the Java Language
>      Specification, sections "Type Variables" and "Parameterized Types":
>      https://docs.oracle.com/javase/specs/jls/se17/html/jls-4.html#jls-4.4
> 
> Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com>
> ---

[...]

> diff --git a/userdiff.c b/userdiff.c
> index d71b82feb7..bc5f3ed4c3 100644
> --- a/userdiff.c
> +++ b/userdiff.c
> @@ -171,7 +171,7 @@ PATTERNS("html",
>   PATTERNS("java",
>   	 "!^[ \t]*(catch|do|for|if|instanceof|new|return|switch|throw|while)\n"
>   	 /* Class, enum, and interface declarations */
> -	 "^[ \t]*(([a-z]+[ \t]+)*(class|enum|interface)[ \t]+[A-Za-z][A-Za-z0-9_$]*[ \t]+.*)$\n"
> +	 "^[ \t]*(([a-z]+[ \t]+)*(class|enum|interface)[ \t]+.*)$\n"
>   	 /* Method definitions; note that constructor signatures are not */
>   	 /* matched because they are indistinguishable from method calls. */
>   	 "^[ \t]*(([A-Za-z_<>&][][?&<>.,A-Za-z_0-9]*[ \t]+)+[A-Za-z_][A-Za-z_0-9]*[ \t]*\\([^;]*)$",

  reply	other threads:[~2023-02-08  0:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-03 23:23 [PATCH v1 0/3] userdiff: Java updates Andrei Rybak
2023-02-03 23:23 ` [PATCH v1 1/3] userdiff: support Java type parameters Andrei Rybak
2023-02-03 23:23 ` [PATCH v1 2/3] userdiff: support Java record types Andrei Rybak
2023-02-03 23:23 ` [PATCH v1 3/3] userdiff: support Java sealed classes Andrei Rybak
2023-02-04  9:22 ` [PATCH v1 0/3] userdiff: Java updates Tassilo Horn
2023-02-04 13:43   ` [PATCH v2 " Andrei Rybak
2023-02-04 13:43     ` [PATCH v2 1/3] userdiff: support Java type parameters Andrei Rybak
2023-02-04 13:43     ` [PATCH v2 2/3] userdiff: support Java record types Andrei Rybak
2023-02-04 13:43     ` [PATCH v2 3/3] userdiff: support Java sealed classes Andrei Rybak
2023-02-05 10:09     ` [PATCH v2 0/3] userdiff: Java updates Johannes Sixt
2023-02-05 19:27       ` Andrei Rybak
2023-02-05 21:33         ` Johannes Sixt
2023-02-07 23:42           ` [PATCH v3 " Andrei Rybak
2023-02-07 23:42             ` [PATCH v3 1/3] userdiff: support Java type parameters Andrei Rybak
2023-02-08  0:04               ` Andrei Rybak [this message]
2023-02-07 23:42             ` [PATCH v3 2/3] userdiff: support Java record types Andrei Rybak
2023-02-07 23:42             ` [PATCH v3 3/3] userdiff: support Java sealed classes Andrei Rybak
2023-02-08 20:51             ` [PATCH v3 0/3] userdiff: Java updates Johannes Sixt
2023-02-08 20:55               ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=152251b7-79a1-9ea9-01de-61a68b729196@gmail.com \
    --to=rybak.a.v@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=pbonzini@redhat.com \
    --cc=peff@peff.net \
    --cc=tsdh@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).