Le 28/02/2018 à 23:00, Eric Sunshine a écrit :
> On Wed, Feb 28, 2018 at 4:31 PM, Alban Gruin <[email protected]> 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.
