Web lists-archives.com

Re: [GSoC][PATCH] userdiff: add built-in pattern for golang




Le 28/02/2018 à 23:00, Eric Sunshine a écrit :
> On Wed, Feb 28, 2018 at 4:31 PM, Alban Gruin <alban.gruin@xxxxxxxxx> wrote:
>>>> diff --git a/userdiff.c b/userdiff.c
>>>> @@ -38,6 +38,15 @@ IPATTERN("fortran",
>>>> +PATTERNS("golang",
>>>> +        /* Functions */
>>>> +        "^[ \t]*(func[ \t]*.*(\\{[ \t]*)?)\n"
>>>
>>> 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 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.
> 
> 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'.
> 

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.