New mklog script

[Martin Liška]

On 5/19/20 10:23 AM, Jakub Jelinek wrote:
> On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote:
>>> I find this format more helpful for the reasons below so unless your
>>> script can be tweaked to do something similar I'd like to be able to
>>> continue to use mine going forward with the new infrastructure.
>>
>> Let's extend the contrib script.
> 
> BTW, concerning mklog, the very common problem is that it doesn't do the
> right thing because the patch doesn't contain enough context to figure out
> what exactly has changed.  If the script would be used together with git
> rather than just on a patch file, perhaps it could handle more, like
> ask git for a patch with unlimited context (like -U100000000 on patch does).

Good idea but the regex parsing takes some time.

> 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");
      }
+
  }

> will result in (label), GTY markers confusing it
>   struct GTY foobar {
>     ...
> -  ...
> +  ...
>   };
> resulting in (struct GTY)

Yes, I know about these and I'll improve stripping of GTY markers.

> or so, another common problem is too large
> function names (or more often *.md define_* names); here I'm afraid
> diff doesn't have an argument to not truncate it, or sometimes e.g. changes
> to #define being attributed to something else.
> I know some of the issues can be pretty hard to deal with.

;)

Martin

> 
> 	Jakub
>