patchuserdiff: add built-in pattern for golang

This adds xfuncname and word_regex patterns for golang, a quite popular programming language. It also includes test cases for the xfuncname regex (t4018) and an updated documentation.

The xfuncname regex finds functions, structs and interfaces. The word_regex pattern finds identifiers, integers, floats, complex numbers and operators, according to the go specification.

Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
---
 Documentation/gitattributes.txt | 2 ++
 t/t4018-diff-funcname.sh        | 1 +
 t/t4018/golang-complex-function | 8 ++++++++
 t/t4018/golang-func             | 4 ++++
 t/t4018/golang-interface        | 4 ++++
 t/t4018/golang-long-func        | 5 +++++
 t/t4018/golang-struct           | 4 ++++
 userdiff.c                      | 9 +++++++++
 8 files changed, 37 insertions(+)
 create mode 100644 t/t4018/golang-complex-function
 create mode 100644 t/t4018/golang-func
 create mode 100644 t/t4018/golang-interface
 create mode 100644 t/t4018/golang-long-func
 create mode 100644 t/t4018/golang-struct

On Wed, Feb 28, 2018 at 12:29 PM, Alban Gruin <alban.gruin@gmail.com> wrote:

s/an //

Most of these files use a mix of spaces and tabs for indentation. Please use tabs only.

Why is the brace (and possible following whitespace) optional? Considering that the language demands that the brace be on the same line, I'd think the brace should be mandatory.

I suppose you made whitespace after 'func' optional to be able to recognize a method (which hasn't been gofmt'd):

    func(x *X) name {

rather than the more typical:

    func (x *X) name {

I wonder if it would make sense to tighten the expression to recognize functions and methods as distinct cases:

    function: mandatory whitespace following 'func'
    method: optional whitespace but mandatory '(' following 'func'

Your current expression could accidentally match:

    /*
      Fish like to have
      functors for lunch {
      just like eels}.
    */

but, even the suggested tighter expression could "accidentally" match example code in a comment block anyhow, so I guess it probably doesn't matter much in practice.

Whitespace is required after 'type'. Good. The language doesn't require '{' to be on the same line as 'struct' or 'interface', and this expression makes it optional. Okay.

I did this to support non-standard formatting. It's a niche case though, maybe we could only support the standard formatting and modify the doc to reflect this change.

Same as before, I did this to support non-standard formatting.

On Wed, Feb 28, 2018 at 4:31 PM, Alban Gruin <alban.gruin@gmail.com> wrote:

As noted, unlike 'struct' and 'interface', the brace for a 'func' _must_ appear on the same line; that's a requirement of the language. Placing it on a line is not an option.

    % cat >foo.go<<\EOF
    package foo
    func foo() {
    }
    EOF
    % go build foo.go

Versus:

    % cat >bar.go<<\EOF
    package bar
    func bar()
    {
    }
    EOF
    % go build bar.go
    ./bar.go:2:6: missing function body
    ./bar.go:3:1: syntax error: unexpected semicolon or newline before {

So, the regex probably ought to be strict about expecting the brace on the same line as 'func'.

Le 28/02/2018 à 23:00, Eric Sunshine a écrit :

Yes, but I can split the line like that:

    % cat >baz.go<<\EOF
    package baz
    func baz(arg1 int64,
    	arg2 int64) {
    }
    EOF
    % go build baz.go

This complies to the standard formatting (at least, gofmt doesn't change it), but making the regex strict about the brace would cause it to ignore those funcs, although I don't know how common they are.

On Wed, Feb 28, 2018 at 5:17 PM, Alban Gruin <alban.gruin@gmail.com> wrote:

Makes sense. Thanks for the clarifying example. I wouldn't be at all surprised it such formatting exists in the wild, so keeping the regex as-is seems a good idea.

Eric Sunshine <sunshine@sunshineco.com> writes:

Does input like that appear in the tests the patch adds? If not, it probably is a good idea to have it somewhere in the commit (even if there is no test addition, having it in the log message to explain why the regex is done like so would be a good idea).

Thanks.

Le 28/02/2018 à 23:32, Junio C Hamano a écrit :

Yes, it's in a file called "golang-long-func". I'll send another patch later to fix the typo in the commit message and the indentation in the tests. I'll clarify the regex in the message, too.

This adds xfuncname and word_regex patterns for golang, a quite popular programming language. It also includes test cases for the xfuncname regex (t4018) and updated documentation.

The xfuncname regex finds functions, structs and interfaces. Although the Go language prohibits the opening brace from being on its own line, the regex does not makes it mandatory, to be able to match `func` statements like this:

    func foo(bar int,
    	baz int) {
    }

This is covered by the test case t4018/golang-long-func.

The word_regex pattern finds identifiers, integers, floats, complex numbers and operators, according to the go specification.

Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
---
 Documentation/gitattributes.txt | 2 ++
 t/t4018-diff-funcname.sh        | 1 +
 t/t4018/golang-complex-function | 8 ++++++++
 t/t4018/golang-func             | 4 ++++
 t/t4018/golang-interface        | 4 ++++
 t/t4018/golang-long-func        | 5 +++++
 t/t4018/golang-struct           | 4 ++++
 userdiff.c                      | 9 +++++++++
 8 files changed, 37 insertions(+)
 create mode 100644 t/t4018/golang-complex-function
 create mode 100644 t/t4018/golang-func
 create mode 100644 t/t4018/golang-interface
 create mode 100644 t/t4018/golang-long-func
 create mode 100644 t/t4018/golang-struct

On Thu, Mar 1, 2018 at 6:19 AM, Alban Gruin <alban.gruin@gmail.com> wrote:

A possible suggested rewrite to make it flow a bit better and to mention the loose whitespace matching:

    The xfuncname regex finds functions, structs and interfaces.
    Although the Go language prohibits the opening brace of a 'func'
    from being on its own line, the regex makes the brace optional so
    it can match function declarations wrapped over multiple lines
    (covered by new test case t4018/golang-long-func):

        func foo(bar int,
            baz int) {
        }

    Whitespace matching is also a bit lax in order to handle
    non-standard formatting of method declarations. For instance:

        func(x *X) foo() {

    versus typical 'gofmt' formatted:

        func (x *x) foo() {

(Not necessarily worth a re-roll; perhaps Junio can pick it up when queueing if he considers it an improvement.)

Thanks.