Re: [PATCH v4 9/9] diff.c: add white space mode to move detection that allows indent changes

[Stefan Beller <sbeller@google.com>]

On Mon, Jul 2, 2018 at 10:36 AM Brandon Williams <bmwill@google.com> wrote:
>
> On 06/28, Stefan Beller wrote:
> > The option of --color-moved has proven to be useful as observed on the
> > mailing list. However when refactoring sometimes the indentation changes,
> > for example when partitioning a functions into smaller helper functions
> > the code usually mostly moved around except for a decrease in indentation.
> >
> > To just review the moved code ignoring the change in indentation, a mode
> > to ignore spaces in the move detection as implemented in a previous patch
> > would be enough.  However the whole move coloring as motivated in commit
> > 2e2d5ac (diff.c: color moved lines differently, 2017-06-30), brought
> > up the notion of the reviewer being able to trust the move of a "block".
> >
> > As there are languages such as python, which depend on proper relative
> > indentation for the control flow of the program, ignoring any white space
> > change in a block would not uphold the promises of 2e2d5ac that allows
> > reviewers to pay less attention to the inside of a block, as inside
> > the reviewer wants to assume the same program flow.
> >
> > This new mode of white space ignorance will take this into account and will
> > only allow the same white space changes per line in each block. This patch
> > even allows only for the same change at the beginning of the lines.
> >
> > As this is a white space mode, it is made exclusive to other white space
> > modes in the move detection.
> >
> > This patch brings some challenges, related to the detection of blocks.
> > We need a white net the catch the possible moved lines, but then need to
>
> s/white/wide/

oops. will fix.

>
> > +
> > +/**
> > + * The struct ws_delta holds white space differences between moved lines, i.e.
> > + * between '+' and '-' lines that have been detected to be a move.
> > + * The string contains the difference in leading white spaces, before the
> > + * rest of the line is compared using the white space config for move
> > + * coloring. The current_longer indicates if the first string in the
> > + * comparision is longer than the second.
> > + */
> > +struct ws_delta {
> > +     char *string;
> > +     unsigned int current_longer : 1;
> >  };
> > +#define WS_DELTA_INIT { NULL, 0 }
> > +
> > +static int compute_ws_delta(const struct emitted_diff_symbol *a,
> > +                          const struct emitted_diff_symbol *b,
> > +                          struct ws_delta *out)
> > +{
> > +     const struct emitted_diff_symbol *longer =  a->len > b->len ? a : b;
> > +     const struct emitted_diff_symbol *shorter = a->len > b->len ? b : a;
> > +     int d = longer->len - shorter->len;
> > +
> > +     out->string = xmemdupz(longer->line, d);
> > +     out->current_longer = (a == longer);
> > +
> > +     return !strncmp(longer->line + d, shorter->line, shorter->len);
> > +}
>
> I'm having a harder time understanding this block.  This is used to fill
> a ws_delta struct by calculating the whitespace delta between two lines.

yes.

> If that is the case then why doesn't this function verify that the first
> 'd' characters in the longer line are indeed whitespace?

This was done implicitly before as compute_ws_delta is called only
on two lines that are "equal with XDF_IGNORE_WHITESPACE".

> Also, maybe
> this is just because I'm not as familiar with the move detection code,
> but how would the whitespace detection handle a line being moved from
> being indented with tabs to spaces or vice versa?  Is this something
> already handled and not an issue?

The ws_delta stores the string (of whitespaces) that the 'shorter string'
needs to be prefixed with to create the 'longer string.
(I chose 'shorter' and 'longer' as any of them can be '+' or '-' lines)

Then later when we compare the strings (the current line in
consideration and strings that we put in hashmaps that we
know are moved lines) in cmp_in_block_with_wsd,
we (should) take this white space delta into account.

I just realize that there we do not check for the tab/space replacement
as there we would need to compare the ws_delta string to the beginning
of the 'longer' string there.

I'll add a test for the space/tab replacement as well.

Thanks,
Stefan