Am 28.05.20 um 01:16 schrieb Jeff King:
> 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
