Re: git grep --show-function treats GOTO labels as function names

From: Johannes Sixt <j6t@kdbg.org>
Date: May 28, 2020, 19:01 UTC
Message-ID: <07f56d7a-45cc-2d28-ec48-51b95015550e@kdbg.org>
In-Reply-To: <20200527231628.GC546534@coredump.intra.peff.net>

Am 28.05.20 um 01:16 schrieb Jeff King:

Show 29 quoted lines

> On Wed, May 27, 2020 at 06:04:21PM -0500, Zach Riggle wrote:
>> It looks like that does the trick for "goto" labels, but there are
>> also some issue on function name parsing with attributes when they are
>> split onto a second line.
>>
>> $ cat attr.cpp
>> int main() __attribute__ ( (no_sanitize("alignment")) )
>> {
>>     FOO
>> }
>> $ git grep --no-index --show-function -e FOO attr.cpp
>> attr.cpp=2=__attribute__ ( (no_sanitize("alignment")) )
>> attr.cpp:4:    FOO
> 
> From your output, I assume the problematic input actually splits the
> attribute onto the second line?
> 
> I agree that's not ideal. The baked-in regex we use for matching C
> function lines is:
> 
>   $ git grep -nA4 cpp userdiff.c
>   userdiff.c:173:PATTERNS("cpp",
>   userdiff.c-174-  /* Jump targets or access declarations */
>   userdiff.c-175-  "!^[ \t]*[A-Za-z_][A-Za-z_0-9]*:[[:space:]]*($|/[/*])\n"
>   userdiff.c-176-  /* functions/methods, variables, and compounds at top level */
>   userdiff.c-177-  "^((::[[:space:]]*)?[A-Za-z_].*)$",
> 
> so we mistake it for a function name. I'm not sure how easy it is to do
> better, though. We can add a line like:

C and C++ have a very versatile syntax and it turned out to be virtually impossible to capture actual function definitions with a regex. See 8a2e8da367f7 ("userdiff: have 'cpp' hunk header pattern catch more C++ anchor points", 2014-03-21) for details.

With the current pattern, we catch probably 95% of the coding patterns and coding styles. The style under discussion falls into the remaining 5% because continuation lines are not indented.

-- Hannes