devel/arcanist-lib: Unbreak "arc list" with php82

[markj]

Summary

In some cases it's possible for arcanist to attempt to call strncmp()
with a null parameter. It seems that this is not allowed in php82, and
causes "arc list" to exit with an exception if the user happens to have
any open differential revisions with a null sourcePath attribute.

Add a patch to work around the problem: if there's no sourcePath, just
treat the source as being different from the current repository.

[karels]

Looks plausible to me, but I don't know php at all.

[jrm]

Looks good to me. Builds and applies fine with php81, which is currently the default PHP version in ports.

[karels]

fwiw, there are separate archanist-php8[012]-* ports, and I arbitrarily chose 82.

[jrm]

In D38221#868793, @karels wrote:

fwiw, there are separate archanist-php8[012]-* ports, and I arbitrarily chose 82.

There is just one port (two if you count devel/arcanist and devel/arcanist-lib). Flavors is what gives support for different php versions.

% make -C/usr/ports/devel/arcanist-lib -VFLAVORS
php81 php80 php82

[karels]

Sorry, I should have said "packages"; I didn't realize that they weren't always 1:1 with ports.

[grembo]

@markj Thanks, I'll look into it

[grembo]

@markj @jrm I just committed be146a923dbda66f50c6b04b406da790837f6287 (cgit link) which addresses the issue in a more generic fashion (since we had these kinds of errors pop up over and over again). Even though I tested this locally and it seems to work as expected, it would be great if you could verify this at your end as well.

[markj]

In D38221#870150, @grembo wrote:

@markj @jrm I just committed be146a923dbda66f50c6b04b406da790837f6287 (cgit link) which addresses the issue in a more generic fashion (since we had these kinds of errors pop up over and over again). Even though I tested this locally and it seems to work as expected, it would be great if you could verify this at your end as well.

Thanks! This fixes the problem that I was able to reproduce.

[jrm]

In D38221#870150, @grembo wrote:

@markj @jrm I just committed be146a923dbda66f50c6b04b406da790837f6287 (cgit link) which addresses the issue in a more generic fashion (since we had these kinds of errors pop up over and over again). Even though I tested this locally and it seems to work as expected, it would be great if you could verify this at your end as well.

Also fixes the problem I was seeing before 3b715073072794942506d27d72b2b23551c4fd30. Thank you.