On 19/05/2020 15:51, Michael Matz wrote:
> Hello,
>
> On Tue, 19 May 2020, Martin Liška wrote:
>
>>> The common problems I remember is that e.g. when changing a function comment
>>> above some function, it is attributed to the previous function rather than
>>> following, labels in function confusing it:
>>> void
>>> foo ()
>>> {
>>> ...
>>> label:
>>> ...
>>> - ...
>>> + ...
>>> }
>>
>> I've just tested that and it will take function for patch context
>> (sem_variable::equals):
>> @@ -1875,6 +1875,7 @@ sem_variable::equals (tree t1, tree t2)
>> default:
>> return return_false_with_msg ("Unknown TREE code reached");
>> }
>> +
>> }
>
> No, the problem happens when the label is at column 0, like function names
> are. Basically diff -p uses a regexp morally equivalent to
> '^[[:alpha:]$_]' to detect function headers, and git diff -p and friends
> followed suit. But it should use something like
> '^[[:alpha:]$_].*[^:]$' to rule out things ending with ':'. See also diff
> -F for GNU diff.
>
>
> Ciao,
> Michael.
>
This is really a wart in the GNU coding style. And one reason why I
tend to indent such labels by a single space. It particularly affects
things like class definitions where public, private, etc statements
often appear in column 0.
IMO, it would be nice to get an official change in the coding style for
this, it's really irritating.
R.
